Minutes of the Fifth OGSI-WG Teleconference 11/Sep/2002 @ 15:00-16:30 GMT Attendees: Tim Banks Karl Czajkowski Shel Finkelstein Fred Maciel Y. Masuoka Andreas Savva Frank Siebenlist David Snelling Peter Vanderbilt 1) We discussed and reviewed the minutes of the Interim Meeting at ANL. The following issues were raised and discussed briefly, however, no changes to the minutes were required. - The GGF time table was confirmed, stressing the point that within the Working Group we expect to have total agreement and a draft spec by December 15, 2002 so that the spec can go for Public comment to the whole of GGF at that time. Oct_01_2002 (XML schemas, most current decisions, some cleaning on text) Oct_13_2002 (Working document for the WG sessions with tracked changes) Nov_12_2002 (All open issues resolved) Dec_15_2002 (Ready for insertion into the GGF process, with the possibility of doing a v1.1) - Tim Banks asked how the name clashes issues was to be resolved serviceType inheritance. The answer is: a) it is a issue with serviceType without inheritance and therefore W3C may address it in some way and we will follow this strategy; b) it is actually a tooling issue, since name clashes for operations are avoided at the WSDL level by the namespace, but the the tooled proxy might have a problem resolving this, c) inheritance of two copies of the same portType should result in the inclusion of only one copy. - Frank Siebenlist asked about the resolution on service instance identity. It was recommended that since it was resolved at this level, a discussion be opened on the mailing list to see if it warrants a second pass. - Tim Banks asked about the justification for strict immutability and the lack of some versioning information. The answer was that the variety of ways in which a service could evolve was much more complex than could be captured in a simple set of rules. Andrew Grimshaw referenced a thesis that outlined this issue. There are also major problems propagating change information, as the GSS has no mechanism of global publication of deprecated functions other than those contained in the spec itself. Action: A. Grimshaw to see if the dissertation referred to can be pushed to the whole mailing list. 2) Technical Discussion of Notification There were three issues raised by D. Snelling for general discussion, the aim being to clarify issues, but with both Steve Graham and Steve Tuecke absent, no effort was made to resolve these. - The distinction between 'void return' and 'no return' in some operations The DeliverNotification, RegisterService, and possibly the Destroy operations all seen to have semantics that imply that nothing comes back from the service instance, neither in the form of a return response nor the presence / absence of a failure. It was generally agreed (also noted in the minutes of the Interim Meeting) that QoS issues such as transaction semantics or reliable delivery were binding level properties. Yet it was still felt important that some form of exception framework be considered for inclusion in the spec. - The specialization of the DeliverNotification operation The DeliverNotification operation in the the NotificationSink portType and any "specialization" of it as a return from Subscribe raised concerns. 1) The concept of "specialization" as described needs clarification. A key issue was whether the signature of the specialization was the same as DeliverNotification or not. If yes, the concept of "specialization" was counter to the notion of refinement or subtyping. If no, it implies dynamic runtime tooling of implementation proxies and access to the WSDL describing the operation. Either way problems exist for further discussion. - Language linking notification subscriptions to SDEs. The spec stresses in the language that Notifications are linked to changes in the state of Service Data. It was acknowledged that it was probably impossible to insist (MUST) on this, but that SHOULD might be worth including to stress the philosophy of the specification, that important state be reflected in the Service Data. The above three issues have been entered into buggzilla. 3) Status of Actions Action: Steve Graham to derive a way to say (as a simple type) DateTime or "Forever". Action: Shel, Dan, Steve G. to check the complexity of deserialization of a DateTime or "Forever". Action: Steve Tuecke to devise language for qname resolution attribute in instance SDEs. Action: Steve Graham to drive the creation of an XML Schema for the specification, #35. Action: Steve Graham and Peter Vanderbilt to address #32 xsd:float use is misleading. Action: Thomas Oinn to summarize the meaning of the presence/absence of service data content. Action: Karl Czajkowski to summarize the meaning of returned states from RegisterService calls (follow up with Create Service). - Done: see Mail "[ogsi-wg] registry:register() semantics" Thu Sep 5, 2002 Action: Shel Finkelstein to write a working definition of Client and some case studies where QoS properties become critical. Action: Steve Graham to craft language for recommendations to developers for use of resolvers. Action: Dave Snelling and Andrew Grimshaw to look at requirements and solutions for pull like semantics. Action: A. Grimshaw to see if the dissertation referred to can be pushed to the whole mailing list. 4) Next Meeting: Time: Wednesday, September 18th 08:00-09:30 US Pacific (GMT - 7) 09:00-10:30 US Mountain (GMT - 6) 10:00-11:30 US Central (GMT - 5) 11:00-12:30 US Eastern (GMT - 4) 15:00-16:30 GMT 16:00-17:30 UK (GMT + 1) 17:00-18:30 Central Europe (GMT + 2) 00:00-01:30 Japan Place: Phone: Phone number: 1-484-630-5376 Pass code: 93031 IRC: DALnet #ogsi 5) Open Issues: - What does a successful return from a RegisterService call? - Track the IPR status of WSIL. - Should WS-Inspection document (or other formats) be explicitly noted in the spec? - What assumptions can be made about the properties of a service resolved by a resolver? - Explore further the implications of subscriptions as Grid Services. #42 The distinction between 'void return' and 'no return' in some operations #43 The specialization of the DeliverNotification operation #44 Language linking notification subscriptions to SDEs.