Minutes for twentieth OGSI-WG Teleconference
February 10, 2003 @ 16:30 - 18:30 GMT
Tim Banks, IBM
Karl Czajkowski, ISI
Shel Finkelstein, Sun
Steve Graham, IBM
Dave Snelling, Fujitsu
Steve Tuecke, ANL
Pete Vanderbilt, NASA
1) Approve minutes of February 5th Teleconference - Skipped
2) Matters Arising from The List
2a) ServiceGroup UniquenessRule:
This facility is too important (powerful) to leave too open. Therefore, we should possibly leave something in there,
possibly as a guide to others implementing extensions.
Rejected: Leave it as it is.
Rejected: Define an example (simple and complete) UniquenessRule.
Resolved: Add returns new entry or fault. Any uniqueness properties are defined in the semantics of the subtype. The
base behavior of the portType is a bag with respect to the ServiceGroup members. No UniquenessRule in ogsi. Review
UniquenessRule for v1.1. Fault: AddRefused.
2b) Fault code:
Do we want fault code in the faults scheme? Does it need to be part of the base class or a subtype?
Vote: Do we add a error code to the GridServiceFault: 2 - for, 3 - against, 1 - abstain.
Resolved: Add to the spec as a minOccurs=0.
Action: Steve G Add to the spec as a minOccurs=0, (Including explanatory text) next time with the pen.
Action make faults: Description minOccurs=0, maxOccurs='unbounded'.
2c) GWSDL vs WSDL 1.1
Review of issues on the list. A major argument against WSDL 1.2 was the impact on tooling.
Action: Steve G to answer issues around SOAP 1.2.
Action: Steve T to talk to Thomas about the tooling issue in more detail.
Action: Steve T to produce a GWSDL Draft.
Resolved: The GSR is either a WSDL 1.1 or WSDL 1.2 document depending on the above.
MEETING STOPPED AT THIS POINT....
The rest to be carried to the next agenda.
3) Review Faults Section
Meta Issue:
From Steve T: The biggest comment/issue that I see is that our model of having each fault
reflected in a WSDL fault element in the operation declaration won't work
for extensible operations such as FindServiceData. Should we go back to having
just a single fault in the WSDL operation of type GridServiceFaultType, which
is extended as necessary?
Questions:
a- Multiple errors in an operation? - Dave S would recommend that the "first" error be the
primary error & others form part of the extensibility element, which may be a sequence
of GridServiceFaults. Not this is not the same thing as the "cause" element.
b- Should there be an AuthorizationFalut?
c- Can a Grid service throw a more general fault than a published fault, e.g throw
SemanticFault, rather than SubscriptionTargetNotFound?
d- In the fault of 6.2.2, what does "the value" refer to in the case of a multi-valued SDE?
Is it talking about one SDE value or the whole set? Should "the value" be replaced by
"one of the values"? - Dave S would recommend that, as above, the "first" error be the
primary error, all others coming in the extensibility element. The extensibility element
could also indicate which SDE was in error.
e- What's the difference between the fault s IncompatibleValueType and IncorrectValue?
Is the intent that IncompatibleValueType indicates a syntactic violation while
IncorrectValue indicates a semantic one? See Set Service Data
f- Should we define an fault meaning "violates service constraints" or perhaps IncorrectValue
would suffice. See Set Service Data.
g- Needed additional faults (see note from GT3 group below) Yes or No.
GridService:findServiceData:, InvalidQuery (semantic), QueryNotSupported (structural)
NotificationSource:subscribe: SubscriptionTargetNotFound - (semantic -assuming this
means the target service cannot be found, rather than a missing locator)
h- What about DeliverNotification in the NotificationSink portType, which is a single
sided operation, i.e. it does not produce an...
View Full Message