Minutes of the First OGSI-WG Interim Meeting
Argonne National Laboratories
4-6/Sep/2002

Attendees:

Bhatia, Karan <Entropia>
Czajkowski, Karl <USC/ISI>
Fay, Dan <Microsoft>
Finkelstein, Shel <Sun>
Graham, Steve <IBM>
Grimshaw, Andrew <Avaki>
Gunabal, John <Entropia>
Karpovich, John <Avaki>
Murphy, Declan <Sun>
Oinn, Thomas <EMBL>
Savva, Andreas <Fujitsu>
Snelling, David <Fujitsu>
Tuecke, Steve <ANL>
Vanderbilt, Peter <NASA>

1) Minutes from August 28, 2002 approved.
 
2) Agenda:

   - Set Agenda
   	- Bugzilla Item Review

   - Discussion Topics
	A - QNames vs. URIs: 18, 33, 34, 32
	B - Registry Discussion
        C - Discussion of Client
	D - Discuss the formal language aspects of serviceType inheritance.
	E - Are QNames resolvable?: 36
	F - Absolute vs relative time: 13, 16, 22, 23
	G - Add a generic setSDE operation to the GridService portType.
	H - Semantics of destroy
	I - Working Group Time line
	J - Change Management: 24, 25
	K - Handles, Sameness: 17!, 26R, 27R, 28R, 29R, 37!, 38!
	L - Notification:

	X - Extensibility patterns: 34
        X - Factory: 5, 19, 34
	X - queryBy issues: 30, 31
	X - Message id: 39
	X - Does minoccurs=1 make sense: 40
	X - Document walk through

3) Discussion Topics:

A - QNames vs. URIs: 18, 32, 33, 34

Background: 
   18 Add gsdl:subscriptionExpression type?
   32 xsd:float use is misleading 
   33 QNames as sole extensibility mechanism 
   34 Model FindServiceData(URI), CreateService(qname),
      Subscribe(URI), & RegisterService(qname) specializations...

A qname is a URI plus a local name from within the namespace referred
to by the URI. In this context, a URI is (possibly resolvable)
reference to a namespace. The spec uses both. Is there a good reason
to use both or should we have only one? There are about 4 places in
the spec where this construct appears. The main goal here is to
provide polymorphic arguments. What do we put in an SDE to describe
content? URI, qname, other structure (input, output, comment).

Resolved: For CreateService, RegisterService, FindServiceData and
Subscribe we will use one extensibility argument. The service infers
what to do based on the tag of the root element of the argument. (#34)

Resolved: In the Service Data, for CreateService, RegisterService,
FindServiceData and Subscribe, we put the qnames of the XSD element
definitions accepted by the service. (#34)

Implication: #33 is resolved as qnames are the sole extensibility mechanism.
Implication: #18 is resolved that no second argument is required.

Please submit written arguments to the contrary.

B - Registry Discussion:
 
Resolved: The RegisterService operation takes two arguments both
required, a Locator and an argument that conforms to one of the qnames
listed in its SD. There may be support provided in the SD for empty or
complex required second arguments.

Resolved: The RegisterService operation is a void RPC operation (with
possible exception).

C - Discussion of Client

Clearly Clients are many things (e.g. Services themselves). "Initiator
of exchanges" was proposed as a starting point (e.g. Requester). What
about persistence? Services have Handles, Clients which are services
will also have these. Part is also related to the binding, but it is
not the whole story. It was also proposed that all entities including
clients have handle. This discussion will continue on the mailing
list, see actions below.

D - Discuss the formal language aspects of serviceType inheritance.

What we are talking about with respect to the specification we are
only talking about interface. We could view it as syntatic sugar, but
it may be more. The closest example is the Java interface inheritance
plus the intent that the semantics are also preserved. The potential
of name clashes was raised, but this is also true of WSDL 1.2. We
should follow their lead.

Discovery issues: There are issues related to how the client tests if
the service...