[note typo in date below- should be 06/Mar/2003]

Minutes of the OGSI-WG GGF7 Second Meeting
06/Feb/2003 @ 12:00-01:30 Japan Time

Attendance 53.

IPR reminder was issued and the agenda agreed.

1) Scalability of ServiceGroupEntry and Subscription. The spec is partly not about implementation. But the working group
 has discussed this at length. There seems to be existing cases that can address these issues. 

2) Locator including multiple GSR's. Withe respect to locator only, there are many uses, return from the factory or 
multiple outputs from a resolver, or even only a reference. There is a loose assumption that the the locator contents 
refer to the "same" instance, but this is not mandated. The locator in resolver is based on a chained resolver protocol.

3) Is a GSR example defined. Yes there is the WSDL definition of GSR in the spec. How this gets encoded in Java would be
 for the Java binding working group. The question appears to be on the boundary between OGSI and the binding layer.

   Action: 7.5.1 "in general" is not normative.

4) ServiceGroup: Content Rule vs addExtensibility. One restricts the content (discovery side) and the other controls 
what the valid arguments can be in the add operation.

5) Do we need portType QNames in the add operation or possibly expand the Locator GSR to include (SHOULD) portType 
information. Some discussion on the current state of the art in EJBs and CORBA about the model of type information in 
the reference. This needs to be lifted to the OGSI level if we are going to expose it.

Proposal: Add a section to locator containing the portTypes implemented by the service refereed to by the locator. This 
list, if present, should be a copy of the portTypes SDE.

Action: Steve T to draft language to the list with a deadline for objections.

6) Version management was not included in the spec other than "all GSs are immutable". A changed PT needs a new name. 
The compatibility issue was dropped early in the process, due to the difficulty in defining what want meant buy 
compatibility and authority of computability testing. So all we have in the spec is support for disambiguation. Most 
operational approaches (e.g. version number operation) only provide a second level naming scheme.

7) Strategy with v2:

Resolved: Doing a v1.1 may be required and we will keep this in mind both in the short term and as an option at in 
addition to a v2, which is likely to wait until WSDL 1.2. This decision will be driven by the measure of the amount of 
work to do with respect WSDL 1.2 and the complexity of our own experiences document.

Reasons to delay starting on v2: Give people confidence, Gain experience, allow development to move on.

8) Future tasks for the WG:

   - Primer
   - Experience document
   - Decide on a v1.1
   - Decide when to do a v2

9) What counts as an independent implementation? We want different people doing the implementations. Refer to the GGF 
rules, which say one or more, but the working group prefers at least two.