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...