Minutes of the Third Interim Face to Face Minutes January 22-24, 2003 Attendees: Shel Finkelstein, Sun Steve Tuecke, ANL Steve Graham, IBM Tom Maguire, IBM Jeffery Frey, IBM Karl Czajkowski, ISI Ellen Stokes, IBM Jay Unger, IBM Dave Snelling, Fujitsu Pete Vanderbilt, NASA 1) Approve previous minutes - OK 2) WSDL Working Group Review The following is an edited extract from Steve Graham's mail reporting from the WSDL Group meeting: "The conclusion the WSDL group reached was to consider that operation names have a combination of namespace name and operation (local) name. The uniqueness constraint is that operation local name (e.g. op name) + namespace must be unique within a portType. Note: we did not explicitly call this a QName, since the WSDL use of QName typically implies a uniqueness and referenceability properties (think portType Qname) which are not appropriate for operations." "One of the WSDL 1.2 Spec authors agreed to write up the following for next Tuesday, in time for discussion on the WSDL WG telecon next Thursday. The rush on this was based on our request (I mentioned about our goal for 02/15 for GS Spec draft). The components of the write up are as follows:" "a) add a namespace property to operation (both at the binding and portType usage), this includes a footnote to clarify why this is not called a Qname" "b) specify the uniqueness constraint in terms of namespace + name of the operation within a portType." "c) explore removing the namespace property from the soap binding (it is now redundant as it would now be part of the operation name)." "d) add a "best practice note" for reusable portTypes (eg when one is designing a portType, make sure the names are unique within the namespace)." Issues: - Are we happy with this? We were not entirely happy with the need to qualify all operations with namespaces, but the overall feeling was that we could live with this improvement compared to the previous state of affairs, e.g. operation names needing to be unique for all time. - Implementation strategy for Grid Services 1) Do XML extended schema for gwsdl:portType (including Open Content and extends) and gwsdl:service to support extension. 2) Use Open Content for Service Data with a Service Data namespace (sd). 3) A note on the issues of overloading and name clashes, unique names within a namespace, differentiation of operations with respect to namespace at both client and server bindings. Action: Steve T. and Steve G. to make sure that the WSDL group is aware of the OGSI's use of the WSDL 1.2 draft. Action: Steve G. clarify the relationship between ports and service in the proposed WSDL 1.2 extension - Done See item (7) below. 3) Contents of the portType Service Data Element. We had the discussion about whether the service description portType SDE should include only the most derived portType or all portTypes explicitly. Resolved: - The maxOccurs="unbounded". - This collection MUST be the transitive closure of the portTypes implemented by the service, e.g. all portTypes of the most derived portType, subject as always to access restrictions. 4) Action Review. Action: Jeff Frey to draw up a description of how to integrate the 'implicit' verses 'SDE' state dichotomy. Also look into other issues of coherency control (#75, #76). - Done Action: Steve T&G to push on W3C to get what we need (portType extension without breaking encapsulation). Take ownership. - Done. Action: Tom Maguire and John R, not being happy with the mutability language, will propose new language reflecting the current meaning. - Dropped. Action: Dave S Faults summary (#42). - Done. Action: Tom M. provide XML Schema and WSDL for the specification. Dependent on service data and some pointers on WSDL 1.2 syntax (#35). - Pending Action: Pete V. to propose a more general solution to the extensibility argument pattern (#34). - Pending. Action: Dave S. and Andrew G. to look at requirements and solutions for pull like semantics (#44). - Dropped. Action: Andrew G to write a document describing the options for reslover behavior (#17). - Pending Action: Steve Graham to craft language for recommendations to developers for use of resolvers (#17). - Pending. Action: Dave to do registry correctly with respect to findServiceDataRedirection and take on board some of the comments and ideas from the Dec 18th teleconference (#50, #63). - Done. 4) Registration The following is a snapshot of the evolving proposal discussed during the meeting. Some resolved changes are listed bellow. Registration <: GS as 1st class citizens. - SD: Content - Mutable, not modifiable?? - SD: Locator - Constant??? A RegistrationSet <: GS keyed by Registration GSHs. - OP: add (locator, content_parms, [lifetime]) -> Locator of a Registration (or GSH?) default lifetime not_before = forever - OP: remove (match Expression) - SD: Content_ParmsTypes - following pattern for extensibility parms (#43) - SD: MatchExpressionTypes, - Constant???? - SD: ContentModel (Homogeneous/heterogeneous via maxOccurs) - Constant??? - SD: UniquenessProperty of the Registration - Constant???? (add could fail subject to this property) A Registry <: RegistrationSet - SD: Collection of (Registration_Locator, GridService_Locator, Content) Issues: Is there a difference between registry and collection? Is the terminology right? Is the life time of a Registration bounded by the registry it is in? Rejected: This would be the typical behavior, but we won't mandate it. Rejected: The RegistrationSet MAY destroy Registrations when the RegistrationSet is destroyed or the Registration removed from the RegistrationSet. Resolved: Once a Registration set is destroyed the client has no responsibility for the destruction of the Registrations. Once a Registration set is destroyed the client can make no assumptions about the existence of the Registrations or the validity of its content (e.g. lifetime properties) of the RegistrationSet. Also, note that a Registration can only belong to one RegistrationSet. If a Grid Service, referenced by a Registration, terminates, the Registration need not reflect this. Naming: Registration -> ServiceGroupEntry RegistrationSet -> ServiceGroup 6 - yes, 3 - no, 1 abstention Match expressions are some kind of expression (XPath?) that returns a boolean. Remove iterates through the all ServiceGroupEntries and remove all those for which the expression evaluates to true. Resolved: Remove the Registry portType and move the triple SDE to ServiceGroup. Note that the Registry as such is not part of the OGSI spec. This issue may therefore want to addressed ate the OGSA-WG. Resolved: Add faults if the Content parameter is not of one of the types in the ContentParameterTypes SDE again following the extensibility patern (#43). Resolved: Add a service data element for sub type of ServiceGroupEntry created by the add. Some open issues are. The UniquenessProperty is not fully defined or agreed. The principal is that add would possibly fail subject to a uniqueness constraint on the locator element, e.g. GSH equality or "Locator Equivalence." 5) Service Data Bifurcation issue: Agreement: Service Data MAY be loosely coherent with the actual state of the service, but this is not mandated by the spec in anyway. Therefore, Service Data MAY be the actual state of the service. Possible words: Clients cannot rely on any coherency semantics of the Service Data. The coherency semantics of Service Data SHOULD be described as part of a service's description. Editor Action: We need to include coherency descriptions of all the Service Data that we define in the spec. Resolved: V 1.0 of the spec will not provide any decoration to reflect the semantics of the Service Data or operations. Note: This mean that the spec will not provide any mechanism to bifurcate the state model. The semantic nature of each SDE will have to be defined by the service designer. Annotation of input/outputs: In the service data spec there are proposed annotations that allow a service author to indicate which service data elements are read/written/modified as a result of an operation. There is also a version for operands. It was felt that this was too much implementation detail to be in an interface specification and was also too much like trying to specify semantics. Resolved: Remove this section (3.5) from the service data document. Resolved: The SD type declarations may be referenced within the WSDL as types (in a similar way to other XSD types), i.e. SDE may be arguments to operations. Action: Steve G. to clarify the spec to make the differences between declaration, value, and element, e.g. clarify the conceptual model of Service Data types etc. Editorial Issue: Should the service data document remain a separate document or be merged into the spec. The primary advantage to a separate document was that it could be presented to other standards bodies. On the single document side, coherency of presentation and the need for accessor operations meant a portType was needed in any case. It was also noted that several of the other standards bodies already wanted to see all of the spec (and the Physiology paper), before considering any aspects of the OGSI. Therefore: Resolved: Define a strategy with respect to addition of authors. The current author list will be changed to "Editors", and "Contributors", and "Acknowledgments" sections added. Individuals on the current author list will be called Editors along with those on the Service Data Document (at their desecration they may chose to be Contributors instead). Resolved: Combine the Service Data paper into one document with carefully delineated chapters that can stand alone as much as possible. 6) Discussion of CRM and its interaction withy OGSA/I. The CRM was a major motivation for the SetServiceData operation. The discussion was general and not critical to the V1.0 spec. An interim version of the document was distributed and discussed within the group. The general release of this document will be in the list for OGSA-WG at GGF7. -------> Amendment to minutes as a result of Jan 29, 2003 Teleconference: <------- At the Jan 29, 2003 teleconference it was requested and agreed that we add a more detailed explanation of this discussion. The CRM document referred to was, at the time, in final review within IBM. Although it was not a proposal to this working group as such, it was felt, by those knowing its content, that our Service Data decisions might effect the potential of this proposal at a later time. We therefore agreed to consider the impact that GSS might have on this proposal as part of our Service Data discussion. The document was provided in hard copy form only, with the request that it be returned at the end of the meeting. I contained a disclaimer the any recall we had of the document following the meeting would not constitute a transfer of knowledge or knowhow. The approach allowed us to consider the document in a pre-release draft form. The chairs of the working group would like to ask that more advance preparation be made in future to allow open discussions to proceed without such complications. -------> End of Amendment to the Minutes <------- 7) Revisit WSDL 1.2 issue based on information from the WSDL WG. Separate bindings can bind to different portTypes, which is good for OGSI. There is no separate list of portTypes that define the service other than those references in the ports declared in the service. 8) Time of calls. Two per week in the final push: January 27, 29 February 3, 5, 10, 12 Time: 08:30-10:00 US Pacific 09:30-11:00 US Mountain 10:30-12:00 US Central 11:30-13:00 US Eastern 15:30-17:00 GMT 16:30-18:00 UK 17:30-19:00 Central Europe 00:30-02:00 Japan (Sorry guys) 9) Editorial Process for the final push: Steve Graham has pen for Service Data merging. Drafts will be published to the whole list with change tracking. New pen holder accepts all changes with review (DS volunteered to be next). Steve T will generate new (readable) XP change tracked version for pdf on the web. 10) Split the GridService portType GSPT into ServiceData portType and GridService portType. This was motivated by the discussion about a separate SD document, which would have benefited from having just the SD accessor methods without the handle management and other GS baggage. In the end , we felt keeping a clear statement of what a Grid Service was (SD plus handles) codified in a single portType that all Grid Services extend was the best approach. Resolved: Keep GridService as a single portType Yes - 6, No - 1, Obs - 2. 11) Define a process to do WSDL bits of the specification. Tom M to take over the creation of the G-WSDL, see edited actions above. 12) Faults Based on the Draft that was pushed to the list: - Put Causes in (e.g. Chaining as recommended by GT3 development team). - Object hierarchy of faults rather than tags - All declared faults listed in the WSDL as individual faults e.g. a full xsd type plus a fault name (the same as the type). - Parent Class - GridServiceFault - Sub classes something like: structural | semantic <: GridServiceFault ?? - Further subclasses to be considered. Action: Dave S to redraft words to this effect including placing all existing operation faults into sub types. We will review this on a future call. 13) GGF7 Plans Option 1: An afternoon tutorial plus a one session. Option 2: Two sessions, one tutorial the other working. The working session agenda: - Process from here - Toward 1.1 issues 14) Pending issues identified, but not dealt with in the three days. "See" you on the calls. *) Set Service Data Review *) Resolver language *) Review Notification status and language. *) Query by locator equivalence *) Service data redirection. *) Extensibility patterns. *) Bugzilla walk through. 15) Actioned Bugs: Bugs with actions assigned. We did not discuss Group A on the call. Bug 17 - Recommend client use of HandleResolver over direct resolver protocols Steve G. and Andrew G. Bug 34 - How to specify choices for extensibility arguments to operations Pete V. and Steve T. Bug 35 - normative XML schema is needed Steve G. and Pete V. Bug 42 - The distinction between 'void return' and 'no return' in some operations Dave S. - Faults summary action. Bug 50 - RegisterService Fault for Registry portType Bug 63 - Replace WSIL (temporarily?) with a simple contents description. Bug 68 - The a Registration a bag or set and what is the key? Bug 69 - Timeout should be added back into the register operation in the Registration protType. Dave S. - Registration portType action. Bug 75 - Bifurcation of Service Data and Service State Bug 76 - Expressing Service Data vs State Bifurcation Jeff F. - Service data thesis action. 16) Open Bugs: Notification Bugs: Bug 43 - The specialization of the DeliverNotification operation Bug 61 - Provide notification of destuction in the GSS Bug 66 - Allow modification of NotificationSubscriptions Bug ?? - Deliver with ack issue?? WSDL Bugs: Bug 62 - Do we need a way to mark operations in a portType optional? Bug 67 - Do we need/have a uniform way of handelling optional arguments? Factory Bugs: Bug 72 - mutability of gsdl:CreatesPortTypes and CreationInputTypes Bug 73 - Factory::CreateService requester as SDE? Bug 74 - strictness of gsdl:CreatesPortTypes commentary Misc Bugs: Bug 70 - Change SDE names from "...Types" to "...Elements" Bug 39 - message identifier for audit Bug 77 - serviceDataNames minOccurs should be 7 Bug 30 - Define queryByXPath Bug 31 - Define queryByXQuery Bug 44 - Language linking notification subscriptions to SDEs. Bug 71 - CPU port-type example SDE inconsistent Bug 81 - GSS and WS-SD need unification. Bugzilla Bug: Bug 80 - bug notifications emails wit autogenerated URL sent to ogsi-wg are incorrect -> Won't Fix Action: Dave S will update bugzilla to reflect the call.