[Requests] Cardinality inconsistances in GetObservationById 10-037 SOS 2.0 interface

Boisvert, Eric Eric.Boisvert at RNCan-NRCan.gc.ca
Thu Nov 25 14:03:28 EST 2010


Part A to be completed once.  Iterate Part B as needed.


PART A


1. Evaluator:
	Eric Boisvert (on behalf of GWIE)
	Geological Survey of Canada / Natural Resources Canada
	T: +01-418-654-3705 F: +01-418-654-2615
      e: eboisver at nrcan.gc.ca

      I-Lin Kuo 
	United States Geological Survey
	T: +01-608-821-3895
	e: ilinkuo at usgs.gov
  
2. Submission: OGC 10-037 SOS 2.0 Interface Standard



PART B


1. Requirement: Requirement 43


2. Implementation Specification Section number: 9.2.1.1


3. Criticality:  Minor


4. Comments/justifications for changes: 

9.2.1.1, Table 23 states that observation pointers is 1..* 
   

While the response (9.2.1.2 table 24) limits the response to a single observation 


Response should return 0 to as many observations than requested. 

On the other hand, the xsd *is* restricted to 1..1 

<complexType name="GetObservationByIdResponseType"> 
               <complexContent> 
                       <extension base="swes:ExtensibleResponseType"> 
                               <sequence> 
                                       <element name="observation"> 
                                               <complexType> 
                                                       <sequence> 
                                                               <element ref="om:OM_Observation"/> 
                                                       </sequence> 
                                               </complexType> 
                                       </element> 
                               </sequence> 
                       </extension> 
               </complexContent> 
       </complexType> 


Correction: The cardinality should either be changed to 1..1 on the request, or changes to 0..* in the response and adjust schemas accordingly.
Our preference is to allow several id to be queries at once to avoid multiple round trip to the server.

PART B


1. Requirement: Requirement 47


2. Implementation Specification Section number: 9.2.1.3


3. Criticality:  Minor


4. Comments/justifications for changes: 

The spec  says that when no observation matches the ID submitted in the request, it shall return an exception (SOS 2.0 is explicit while SOS 1.0 was not) 

GetObservation, on the other hand, would just return an empty collection if nothing matches request parameters. I think those two behaviours are inconsistent. 
Empty response, consistant with a query that does not match any record, shall be returned when nothing matched. 

================================================================
Eric Boisvert
Spécialiste TI-GI / IT-IM specialist
Eric.Boisvert at rncan.gc.ca, 418-654-3705, facsimile/télécopieur 
418-654-2615
490, rue de la Couronne, Québec (Québec), G1K 9A9
490, rue de la Couronne, Quebec, Quebec, G1K 9A9

Laboratoire de cartographie numérique et de photogrammétrie (LCNP)
Digital Cartography and Photogrammetry Laboratory (DCPL)
Commission géologique du Canada (Québec) / Geological Survey of Canada (Quebec)
Ressources naturelles Canada / Natural Resources Canada
Gouvernement du Canada / Government of Canada
http://cgc.rncan.gc.ca/org/quebec
http://cgc.rncan.gc.ca/dir/index_f.php?id=4186 / http://cgc.rncan.gc.ca/dir/index_e.php?id=4186




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/requests/attachments/20101125/3269ceab/attachment.htm>


More information about the Requests mailing list