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.