[Requests] SPS (RFPC 34) Response

[Johannes Echterhoff]

PART A
------

1. Evaluator:

Johannes Echterhoff
Institute for Geoinformatics
University of Muenster
Robert-Koch-Strasse 26 - 28
48149 Muenster
Germany
email: echterhoff at uni-muenster.de

2. Submission: OGC Request 34, Sensor Planning Service (SPS)


PART B
------

B.1
-----
1. Specification Section number: GENERAL
2. Criticality: MAJOR
3. Comments/justifications for changes:
Consider a SPS with many taskable sensors. The IDs of these sensors may 
be changed by the SPS operator or some sensors might be removed from the 
service (e.g. if the sensor was sorted out or destroyed). How can the 
SPS communicate to the client that a request could not be performed 
because the sensorID given in the request is not / no longer known to 
the service? Therefore I suggest defining another exception code for the 
SPS:

exceptionCode value: UnknownSensorID
Meaning of code: sensorID that has been issued by the client is not 
known to the SPS.
"locator" value: (comma separated list of) the unknown sensorID(s)

This exception code should be added to the codes for the operations: 
DescribeTasking, GetFeasibility, Submit and DescribeResultAccess

B.2
-----
1. Specification Section number: 11.2.1 InputDescriptor
2. Criticality: MAJOR
3. Comments/justifications for changes:
The InputDescriptor defines a parameter which can be used when tasking a 
sensor. One choice to define the type of the parameter's value is to use 
a 'swe:DataDefinition' element. That element defines - among other 
things - the encoding to use when delivering the value (at least as far 
as the SPS is concerned, a SOS uses it for specifying which encoding was 
used for sensor data delivered by the service). The InputParameter 
defined by the spec to contain the delivered values uses an 'xs:any' 
element. As such an element can only contain XML, the spec should 
mention that - as far as the SPS is concerned - the only possible 
encoding is StandardFormat with mimeType 'text/xml' (as is shown in the 
example listings). The SPS should not create InputDescriptors that 
contain a swe:DataDefinition that defines AsciiBlock, BinaryBlock or 
StandardFormat with a mimeType other than 'text/xml' as encoding because 
a client would not be able to provide such input in a valid InputParameter.

B.3
-----
1. Specification Section number: 13.3 - DescribeTasking operation response
2. Criticality: MAJOR
3. Comments/justifications for changes:
The gml:description element in a DescribeTasking response should be a 
child of the taskingDescriptor element, not of the 
DescribeTaskingRequestResponse element (or at least both elements should 
have a gml:description). This would make more sense to me because thus a 
SPS could provide a sensor-specific description for each requested 
sensor and a client could automatically provide this description in the 
GUI or save it together with the InputDescriptors of a certain sensor.

B.4
-----
1. Specification Section number: 16.3 - GetStatus operation response
2. Criticality: MINOR
3. Comments/justifications for changes:
In some cases the SPS operator might cancel / delay a certain task. Then 
the optional 'gml:description' element should indicate why the task was 
cancelled / delayed. The spec should contain a comment or phrase (maybe 
as a note to table 18) like the following:
"Note: if the SPS operator cancelled or delayed the task then the 
gml:description should be considered as a mandatory element explaining 
why the task was cancelled or delayed. If the task was delayed by the 
operator then the sps:estimatedToC element should - if possible - 
indicate when the task is supposed to be finished despite the delay."

B.5
-----
1. Specification Section number: 18.3 - Cancel operation response
2. Criticality: MINOR
3. Comments/justifications for changes:
The value "incomplete request" of the 'sps:requestStatus' element in the 
Cancel response could confuse the reader. A valid Cancel request can 
never be incomplete because only the taskID has to be provided. Thus a 
note like the following should be added to the spec (maybe to table 24):
"Note: if the requestStatus element contains 'incomplete request' the 
request can be regarded as being 'rejected' by the SPS."

B.6
-----
1. Specification Section number: 19.2 DescribeResultAccess operation
2. Criticality: EDITORIAL
3. Comments/justifications for changes:
Figure 47 does not reflect figure 48 and table 26: in figure 47 a 
DescribeResultAccess request must contain both a sensorID and a taskID, 
but only one of those elements must be used in a request. Figure 47 
should thus be updated.

B.7
-----
1. Specification Section number: 19.3 - DescribeResultAccess operation 
response
2. Criticality: MINOR
3. Comments/justifications for changes:
I wonder whether an 'xs:any' element should be added as a child to the 
'service' element in a DescribeResultAccess response. Is the ServiceType 
and ServiceURL enough information to access the data gathered in a 
certain task? The 'xs:any' element could contain additional information, 
e.g. an access-ID specific for that service or maybe the GetObservation 
request to access the data stored in a SOS. Maybe this 'workaround' 
should be introduced and later be replaced by a list of concrete 
elements used for accessing task-specific data provided by services of 
various type.

B.8
-----
1. Specification Section number: 20 SPS – running example
2. Criticality: EDITORIAL
3. Comments/justifications for changes:
Listing 20-6 is not consistent with the other example listings, 
especially listing 20-5. The type of the InputParameters 'pan' and 
'tilt' in listing 20-6 should be 'swe:Quantity', as was defined in 
listing 20-5, and not 'swe:Count'.

B.9
-----
1. Specification Section number: B.19 spsMessageSchema.xsd
2. Criticality: MAJOR
3. Comments/justifications for changes:
"status unknown" and "status known" should be added as values to the 
'status' element in a 'StatusInformation' element. Thus there would be a 
complete linking between the possible states of a task a client might 
encounter in a GetStatus response. A statechart could be added to the 
spec that pictures the states of a task and the transitions between them 
together with the messages sent by the SPS.