[Requests] comments on SOS 2.0 RFC

Jeff de La Beaujardiere jeffdlb at gmail.com
Wed Dec 1 22:18:28 EST 2010


PART A

1. Evaluator:
         Jeff de La Beaujardière, PhD
	Integrated Ocean Observing System (IOOS)  Program Office
	National Oceanic and Atmospheric Administration
	(NOTE: These comments are mine alone and have not been circulated to or
	approved by colleagues at IOOS or NOAA)

2. Submission: OGC document #10-037, Sensor Observation Service 2.0 candidate standard

PART B.1

1. Requirement: Specification lacks informative, plain-English explanation of how a
data provider should establish an SOS, and how a data consumer should access an SOS.

2. Implementation Specification Section number: General

3. Criticality: Major

4. Comments/justifications for changes:

SOS version 1 contained useful discussion in Clauses 6 (SOS Overview) and 7 (SOS
Concept of Operations). These discussions have been omitted in SOS v.2, and should
be updated and included. The Scope section (Clause 1) is minimal, and is followed
immediately by an enumeration of conformance classes.  Perhaps this is a result of
new guidance by OGC regarding the structure of specification documents; if so,
that guidance is flawed in my opinion.

Interoperability specifications are only useful if many groups adopt them.
Adoption relies as much on proper marketing as it does on technical suitability.
Therefore, in my opinion every new OGC Standard including SOS 2.0 should have an
informative, plain-English discussion that clearly explains what the specification
does, and is detailed enough to be implementable with a reasonable degree of
correctness and compatibility with other implementations. This narrative should
reference specific technical material, located later in the same document or in a
separate document, in the form of UML models, XML schema, conformance clauses and
other normative statements that resolve any ambiguities in the narrative and provide
testability.  I would go so far as to say that the OGC TC process should be modified
to require that the narrative concept of operations be written first and approved by
the TC membership prior to the writing of the more detailed specification material.


PART B.2

1. Requirement: "Observation Offering" model is too loosely defined and contains
potentially redundant information.

2. Implementation Specification Section number: Clause 8.1.2.2 and elsewhere

3. Criticality: Major

4. Comments/justifications for changes:

An Observation Offering may include a 'swes:procedure', 'swes:identifier', and 'swes:id'.
If both procedure and identifier are provided, they are redundant unless the
difference between them is clearly explained. The spec does not provide such an
explanation. The swes:id attribute is another potentially redundant element: in theory
it could be completely opaque and unique only within the document instance
(Capabilities XML), but in practice data providers may prefer a constant value of the id
for a given offering, which means they must think of and assign an ID value, which results
in another, different ID (which, furthermore, is an XML ID and therefore is
very constrained in allowed character content).

Also, Table 18 states that the GetObservation request may include a pointer to an
Observation Offering, but does not specify whether the value of that pointer should be
'swes:procedure', 'swes:identifier', or 'swes:id' (or something else).

Finally, in SOS v.1, an Offering also could contain a featureOfInterest, but in v.2 it
appears that a featureOfInterestType is allowed instead. The reason for and implications
of this change are not clearly explained. Furthermore, the definition of GetObservation
(Table 18) says that featureOfInterest is a possible request parameter, but it is not
clear where the FOIs come from if the server does not implement GetFeatureOfInterest.

PART B.3

1. Requirement: There are not two or more independent implementations of SOS 2.0 from
different vendors.  

2. Implementation Specification Section number: General

3. Criticality: Major

4. Comments/justifications for changes:

A specification document has been written, but there is no evidence that two or more
independent organizations have written conformant software to assess the suitability of
provisions in the specification. At present, therefore, the specification appears to
be merely a theoretical exercise.  I represent an interagency group that must make
technical decisions whether to update our SOS 1.0 implementations to conform with SOS 2.0.
At present, I could not recommend adoption of SOS 2.0 by our operational (24/7/365)
data providers because of the lack of conformant implementation experience and the other
concerns cited above.




More information about the Requests mailing list