[note date in minutes apparently wrong- these notes copied from original OGSI-WG site verbatum]

Minutes for Nineteenth OGSI-WG Teleconference
February 5, 2003 @ 18:00 - 20:00 GMT

Karl Czajkowski, ISI 
Shel Finkelstein, Sun
Dave Snelling, Fujitsu 
Steve Tuecke, ANL 
Pete Vanderbilt, NASA 
Andera Westerinen, Cisco


1) Approved minutes of February 3rd Teleconference

2) Review of ServiceGroup Section. Specific identified questions:


   a- Do we need a definition of GSH or Locator equivalence as a basic UniquenessRule?
      Resolved: Only null equivalence in the spec.

      Do we need to specify what the �equired�set of UniquenessRules might be?
      Resolved: No required set of rules required.


   b- Shouldn't the UniquenessRule apply to the content (as well as to the locator)?
      Resolved: UniquenessRule is not limited to Locator or Content only. Anything goes.


   c- Should we do an XPath expression for Locator equality or equivalence or just
      plain language semantics? 
      Resolved: No: Answered above.

   e- Since the text talks about comparing locators, shouldn't that concept be defined?
      What's the definition?  Is it general enough that it might go in section 7.5.3?
      Resolved: No: Answered above.

   f- The same pattern may be needed by developers wanting to include UniquenessRules.
      At present it just says a QName, so we can implement it as just plain language,
      but someday we may need more. Do we point the way now?
      Resolved: UniquenessRule should be element rather than QName.

   g- Check min/maxOccurs, mutibility etc. (e.g. ContentModelType mutability=extends?)
      Resolved: Change it to static, which follows the general pattern elsewhere.
      Resolved: The Content is the QName of the element of the Content SDE of the entry.

   h- Do we need to define "coherent" with respect to the Entry and the SD of the SGEntry?
      Resolved: The word coherent is too strong. Find looser language that allows
                the two views to differ for a while.


2a) General discussion on the approach to capturing both the argument type (possible
    with just a QName) and some of the semantics in the form of an element. This is a
    powerful concept, but do we really need it in the spec.

    Action: Steve T to do a proposal for a more general solution to parameterized typing
            following the Uniqueness Rule model.

2b) Resolved: ServiceGroupEntryType: Text to say it MUST be a sub type of ServiceGroupEntry.
              NB: nil implies ServiceGroupEntry.


3) Review Faults Section - Not discussed on the call.

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