Object model Telecon, July 17, 2001
Updated: July 17, 2001 15:45 - Page Maintained by Allan Doyle

Present

Yonsook Enloe
Allan Doyle
George Percivall
Arliss Whiteside
Lou Reich
Carl Reed
Harry Niedzwiadek
Peter Vretanos
Serge Margoulies

Agenda in black, discussion during telecon in blue, action items in red

Agenda - Discuss type hierarchy...

OGC terminology for what we're talking about is Catalog Service as opposed to Library Service or Data Service (see email discussion of last two days). Peter's note was about the interface types, not a taxonomy. Is it the case that the generalized object server is part of the type hierarchy and the Catalog/Library issue is a service taxonomy?

Constructs such as "filter" or "searchable" are really "flavors" of an operation, not disctinct operations and we want to consider how to document whether a given operation supports these.

We're not clear on what Serge is looking for based on his message of yesterday in response to Peter's "partial hierarchy".

Peter's message was trying to make the point that we have a "soup" of operations and depending on how you mix and match these, they wind up defining different services.

[Should we really say a "soup" of interfaces?] - Some say yes, others say that we should stick with mixing the operations. "Operation" is what you invoke. Interface is a grouping. Service is a higher level grouping. Operations are the things you parse when decoding parameters. These are the things you want to re-use.

Right now interface = group of operations (1..n); OOD - Natural cohesion; If operation is like get/set of CORBA, these are not really useful in their own right. In web services because we have larger chunks, the distinction between Interface/Operation or Service/Interface gets blurry. Is a Transaction an interface with operations (insert, update, delete) and WFS a service which may or may not include Transactions?

UML has a very specific definition of operation and it's different from what Peter described with Transaction. A Transaction of a WFS is an operation. It can contain "sub-operations" since the insert/update/delete are really scripted in XML and are handed into an internal mechanism that parses these out and acts on them.

GetFeature has a "search" operation and a "present" operation. I.e. it picks out features based on constraints and also picks what parts of the features it will return to the client. (Again, these are really "sub operations" within a single UML:operation).

UML - operation is something that's individually callable. Interface combines 1 or more operations. Service is not a UML term. The closest thing UML has is "component". (See table)

Might be worth looking at SQL (or ODBC) as another perspective on the issue of terminology [I missed some of this discussion - maybe Peter could fill this in if he thinks it's still important...]

Clarification on UML - we're not pushing to use UML as the final set of terms, we're pushing to use UML as the baseline against which we try to understand things.

We're tabling the terminology discussion unless it gets in the way to not have finished it...

Back to the type hierarchy...

Serge - what's the difference between the WFS and the WMS? They really do a lot of the same stuff, the difference is that the WMS can be extended from a WFS as a "value-adding" interface that adds presentation. Peter's "Partial Hierarchy" - a LOF server is a type of a WFS, a catalog is a type of a WFS... These all have the same signature as a WFS, they only extend the WFS at a semantic level. E.g. a Geocoder is extending the WFS only in terms of the more strongly typed response. (i.e. a location is more specific than a feature).

Two concepts - "restriction" and "extension". Peter's hierarchy was largely by restriction.

Lou tried to build a catalog from a WFS, found that he had to add to the signatures (e.g. can you sort the result set). Thus a catalog is both an extension and a restriction. This led Lou to say that there was a more "primitive" base class from which a Catalog and a WFS were both inherited, one perhaps by restriction, the other by extension (or a mixture).

In GFSPP or MPP- new functionality had to be added to filter (like sort). These services are often only differentiated by the content of the capabilities.

We may have enough material based on this telecon to write up a more UML-ish model of a type hierarchy. Serge can do this for Friday. Action - Serge - provide a model that includes Peter's branch and Serge's branch for July 20.

The reason for having a "neutral" base class above WFS is to remove the "feature" terminology and allow the WFS to add it back in by extension or restriction. We do have to understand how to differentiate among things whose only difference is the service content of the capabilities (i.e. the semantic content).

Reiterated the importance of adding to John D's GSM document.