Change Requests | OGC
OGC Doc 08-032
Open Geospatial Consortium
Combined SPS CRs from OWS-5 CITE
This document contains the change requests that address issues identified in the OWS-5 CITE
thread for SPS (07-014r3).
CR-Form-v3
CHANGE REQUEST
SPS 1.0.0 CR ?
rev
-
Current version:
1.0.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the symbols.
Proposed change affects:
AS
Imp Spec X
Title:
SweCommon examples incorrect
Source:
OWS-5 CITE thread
Best Practices Paper
Work item code:
Category:
Other
Date: 2008-02-06
F
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier
release)
B (Addition of feature),
C (Functional modification of feature)
D (Editorial modification)
Detailed explanations of the above categories can
be found in the TC Policies and Procedures.
Reason for change:
Some examples in the spec do not seem to be valid according to the current
SweCommon schema baseline. This should be fixed throughout the document.
Summary of change: Go through each example and fix it if necessary.
Consequences if
not approved:
Users / readers of the specification would create incorrect requests / responses.
Clauses affected:
throughout
Other specs
Affected:
Supporting Doc.
Other comments:
Status
Disposition
Other core specifications
Abstract specifications
Best Practices Document
NEW
The OGC Technical Committee Policies & Procedures 05-020r3
CR-Form-v3
CHANGE REQUEST
SPS 1.0.0 CR ?
rev
-
Current version:
1.0.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the symbols.
Proposed change affects:
AS
Imp Spec X
Best Practices Paper
Title:
Definition of valid IDs (sensorID, taskID, feasibilityID)
Source:
OWS-5 CITE thread
Work item code:
Category:
Other
Date: 2008-02-06
D
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier
release)
B (Addition of feature),
C (Functional modification of feature)
D (Editorial modification)
Detailed explanations of the above categories can
be found in the TC Policies and Procedures.
Reason for change:
When creating IDs the schema + specification should make sure that only
meaningful IDs are created by an SPS.
Summary of change: Make sure that an ID is not nillable and that it is a non-empty string.
Consequences if
not approved:
Empty ID fields (or fields with empty strings) would still be valid according to the
schema and spec.
Clauses affected:
Clause 11 (Shared aspects) and subclauses
Other specs
Affected:
Supporting Doc.
Other comments:
Status
Disposition
Other core specifications
Abstract specifications
Best Practices Document
NEW
CR-Form-v3
CHANGE REQUEST
SPS 1.0.0 CR ?
rev
-
Current version:
1.0.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the symbols.
Last Revision Date: 2 December 2017
Page2
The OGC Technical Committee Policies & Procedures 05-020r3
Proposed change affects:
AS
Imp Spec X
Best Practices Paper
Title:
Usage of InvalidParameterValue exception
Source:
OWS-5 CITE thread
Work item code:
Category:
Other
Date: 2008-02-06
F
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier
release)
B (Addition of feature),
C (Functional modification of feature)
D (Editorial modification)
Detailed explanations of the above categories can
be found in the TC Policies and Procedures.
Reason for change:
If the use of the InvalidParameterValue exception is not defined clearly
implementers would not make correct use of the exception + clients do not know
what to expect.
Summary of change: State that each time a mandatory request element is nil or contains an empty
string, this should cause an InvalidParameterValue exception.
Consequences if
not approved:
Usage of InvalidParameterValue exception would be confused by both client and
service developers.
Clauses affected:
Clause 11 (Shared Aspects) or throughout
Other specs
Affected:
Supporting Doc.
Other comments:
Status
Disposition
Other core specifications
Abstract specifications
Best Practices Document
NEW
CR-Form-v3
CHANGE REQUEST
SPS 1.0.0 CR ?
rev
-
Current version:
1.0.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the symbols.
Proposed change affects:
AS
Imp Spec X
Title:
Schema structure in SPS
Source:
OWS-5 CITE thread
Work item code:
Category:
Best Practices Paper
Other
Date: 2008-02-06
D
Last Revision Date: 2 December 2017
Page3
The OGC Technical Committee Policies & Procedures 05-020r3
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier
release)
B (Addition of feature),
C (Functional modification of feature)
D (Editorial modification)
Detailed explanations of the above categories can
be found in the TC Policies and Procedures.
Reason for change:
It would make life easier for client developers if they could reuse global
elements defined in the SPS schema. Also, operation (schema) names and
types contain unnecessary “Request” token. Following rules of object->property>value rules in schema creation would also be nice.
Summary of change: Make Subelements in the SPS schema global where possible and where useful.
For example the DescribeResultAccessRequestResponse could be splitted up.
This would make life easier for developers who can reuse these elements.
Maybe one should make more use of the general element/property/value
approach as well. Also remove unnecessary “Request” token in operation
(schema) names and types.
Consequences if
not approved:
Clauses affected:
Other specs
Affected:
Supporting Doc.
Other comments:
Status
Disposition
Other core specifications
Abstract specifications
Best Practices Document
NEW
CR-Form-v3
CHANGE REQUEST
SPS 1.0.0 CR ?
rev
-
Current version:
1.0.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the symbols.
Proposed change affects:
AS
Imp Spec X
Best Practices Paper
Title:
Improvement of operation request and response descriptions.
Source:
OWS-5 CITE thread
Work item code:
Category:
Other
Date: 2008-02-06
F
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier
release)
Last Revision Date: 2 December 2017
Page4
The OGC Technical Committee Policies & Procedures 05-020r3
B (Addition of feature),
C (Functional modification of feature)
D (Editorial modification)
Detailed explanations of the above categories can
be found in the TC Policies and Procedures.
Reason for change:
Good description for requests and responses is not given directly at the
operation level but rather in the running example. All semantics that are
essential to each operation should be described right there and not in an Annex
or other chapter which might easily be missed.
Summary of change: Provide general description for request / response elements and their meaning
directly instead of in the running example. For example, a thorough description
of the timeFrame parameter in a Submit request can only be found in the
running example.
Consequences if
not approved:
The true (intended) semantics of an operation might be missed by a reader.
Clauses affected:
throughout
Other specs
Affected:
Supporting Doc.
Other comments:
Status
Disposition
Other core specifications
Abstract specifications
Best Practices Document
NEW
CR-Form-v3
CHANGE REQUEST
SPS 1.0.0 CR ?
rev
-
Current version:
1.0.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the symbols.
Proposed change affects:
AS
Imp Spec X
Title:
General task timing approach
Source:
OWS-5 CITE thread
Best Practices Paper
Work item code:
Category:
Other
Date: 2008-02-06
B
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier
release)
B (Addition of feature),
C (Functional modification of feature)
D (Editorial modification)
Detailed explanations of the above categories can
be found in the TC Policies and Procedures.
Last Revision Date: 2 December 2017
Page5
The OGC Technical Committee Policies & Procedures 05-020r3
Reason for change:
It would be good to allow a client to specify a time period for when a task should
be completed. This could be handled on a sensor by sensor basis through the
tasking parameters of the tasking message (i.e. task-start-time and task-endtime as in the 52N Axis SPS), but it might make sense to make it a
standard/optional part of the Submit request (if it's universally appropriate).
Being able to control / parameterize a sensor at a certain time (period), making
sure that a task is completed before a certain point in time and also that data is
available at a certain time plays a role here. For instance, a user might want a
satellite to take a picture of a certain area by tomorrow. The SPS could use the
constraint that the task needs to be completed by tomorrow to determine if the
task is feasible or not, rather than simply queueing up the task and telling the
user that his or her task will be completed by X date/time (assuming the SPS
queues tasking requests).
Summary of change: Consider this new feature in SWG. The GetFeasibility and Submit request might
contain the elements for the new feature (if approved) by default or maybe the
spec could define usage of SweCommon for this.
Consequences if
not approved:
Clauses affected:
Other specs
Affected:
Supporting Doc.
Other comments:
Status
Disposition
Other core specifications
Abstract specifications
Best Practices Document
NEW
CR-Form-v3
CHANGE REQUEST
SPS 1.0.0 CR ?
rev
-
Current version:
1.0.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the symbols.
Proposed change affects:
AS
Imp Spec X
Title:
Handling of submitted tasks
Source:
OWS-5 CITE thread
Best Practices Paper
Work item code:
Category:
Other
Date: 2008-02-06
B
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier
release)
B (Addition of feature),
C (Functional modification of feature)
D (Editorial modification)
Detailed explanations of the above categories can
Last Revision Date: 2 December 2017
Page6
The OGC Technical Committee Policies & Procedures 05-020r3
be found in the TC Policies and Procedures.
Reason for change:
We do not have any parameter in the sensors interface with which a client could
indicate when the task should take place. Thus it is up to the sensor to decide
when it will be performed. The apparent assumption that a task takes place
directly after it was submitted is not guaranteed to hold true in all cases. Think
for example of a simulation encapsulated behind an SPS: if ten tasks are
submitted, the simulation could put all of them in a queue and work on them one
after the other. A stupid sensor on the other hand might only be capable of
waiting for a task, performing it, ignoring all Submit requests during task
execution and then waiting again. These are all feasible behaviour for sensors
facaded by an SPS. The question is if the SPS interface should indicate how a
sensor handles tasks.
Summary of change: Consider this new feature in SWG. Maybe this could be done by adding an
attribute or element to each SensorOffering in the Capabilities of the SPS that
just takes a code. The OGC (or some other domain) could then create a list of
possible behavior with a code for each.
Consequences if
not approved:
Task handling by the service will still be a guess by the client. It would be quite
hard to define any policies / guarantees between service and client if the task
handling was not defined.
Clauses affected:
throughout
Other specs
Affected:
Supporting Doc.
Other comments:
Status
Disposition
Other core specifications
Abstract specifications
Best Practices Document
NEW
CR-Form-v3
CHANGE REQUEST
SPS 1.0.0 CR ?
rev
-
Current version:
1.0.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the symbols.
Proposed change affects:
AS
Imp Spec X
Best Practices Paper
Other
Title:
Guarantee match between procedure IDs and ID contained in sensor description
document.
Source:
OWS-5 CITE thread
Work item code:
Category:
Date: 2008-02-11
B
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier
release)
B (Addition of feature),
Last Revision Date: 2 December 2017
Page7
The OGC Technical Committee Policies & Procedures 05-020r3
C (Functional modification of feature)
D (Editorial modification)
Detailed explanations of the above categories can
be found in the TC Policies and Procedures.
Reason for change:
Right now it is up to the provider of the service how a certain sensor is identified
at his service. Thus, the link between a sensor and its sensor description (either
SensorML or TML) is implicit by the grouping of a SensorID and the link to the
sensors description in a SensorOffering.
But in cases where the same sensor is registered at multiple services (maybe at
different service types, so for example at SOS, SAS and SPS) one does not
directly see that the ID of a specific sensor actually means the same. Only by
checking an ID that is possibly contained in the sensor description and
comparing those one could derive the information that some sensor IDs at
multiple services are actually identifying the same sensor. So it would be
preferred that both the sensor description (we will write a Change Request for
SensorML to make sure that the way to include such an identifier is specified in
SensorML) and the service offering both use the same identifier.
Summary of change: Specify that a sensor’s ID has to be the same as the one contained in its sensor
description.
Consequences if
not approved:
Being able to clearly identify sensors across service boundaries would still not be
possible.
Clauses affected:
Throughout (the introductory clauses as well as the description of the Contents
section)
Other specs
Affected:
Supporting Doc.
Other comments:
Status
Disposition
Other core specifications
Abstract specifications
Best Practices Document
NEW
CR-Form-v3
CHANGE REQUEST
SPS 1.0.0 CR ?
rev
-
Current version:
1.0.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the symbols.
Proposed change affects:
AS
Imp Spec X
Title:
Default value(s) in InputDescriptors
Source:
OWS-5 CITE thread
Best Practices Paper
Work item code:
Category:
Other
Date: 2008-02-06
B
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier
Last Revision Date: 2 December 2017
Page8
The OGC Technical Committee Policies & Procedures 05-020r3
release)
B (Addition of feature),
C (Functional modification of feature)
D (Editorial modification)
Detailed explanations of the above categories can
be found in the TC Policies and Procedures.
Reason for change:
Oftentimes it might be easier for a service to define a default value for a
parameter and the client might just agree with it or at least have an idea of what
value could be provided to the service. So it makes sense to define how a
default value can be put in an InputDescriptor.
Summary of change: Define how default values can be put in an InputDescriptor. If SweCommon is
used, this could be done by simply providing a value in the responding
SweCommon element.
Consequences if
not approved:
Clauses affected:
Clause 11.2.1
Other specs
Affected:
Supporting Doc.
Other comments:
Status
Disposition
Other core specifications
Abstract specifications
Best Practices Document
NEW
CR-Form-v3
CHANGE REQUEST
SPS 1.0.0 CR ?
rev
-
Current version:
1.0.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the symbols.
Proposed change affects:
AS
Imp Spec X
Best Practices Paper
Title:
Clarification on restriction element in InputDescriptor
Source:
OWS-5 CITE thread
Work item code:
Category:
Other
Date: 2008-02-06
D
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier
release)
B (Addition of feature),
C (Functional modification of feature)
D (Editorial modification)
Detailed explanations of the above categories can
be found in the TC Policies and Procedures.
Last Revision Date: 2 December 2017
Page9
The OGC Technical Committee Policies & Procedures 05-020r3
Reason for change:
It is not clearly defined when the restriction element in an InputDescriptor should
be used exactly. In the beginning of OWS-3 SweCommon did not have
constraints on its simple types, now it has. So the use of the restriction element
is no longer needed in every case.
Summary of change: Clearly define usage of restriction element in an InputDescriptor and give an
example when it can be applied.
Consequences if
not approved:
Clauses affected:
Clause 11.2.1
Other specs
Affected:
Supporting Doc.
Other comments:
Status
Disposition
Other core specifications
Abstract specifications
Best Practices Document
NEW
CR-Form-v3
CHANGE REQUEST
SPS 1.0.0 CR ?
rev
-
Current version:
1.0.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the symbols.
Proposed change affects:
AS
Imp Spec X
Best Practices Paper
Title:
Clarification of InputParameter content encoding / creation
Source:
OWS-5 CITE thread
Work item code:
Category:
Other
Date: 2008-02-06
F
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier
release)
B (Addition of feature),
C (Functional modification of feature)
D (Editorial modification)
Detailed explanations of the above categories can
be found in the TC Policies and Procedures.
Reason for change:
Right now only the examples (and even those are not 100% correct) show how
an InputParameter should be created based upon an InputDescriptor. When
describing the InputParameter element, the spec should also describe in detail
how the content of this element is expected to be derived from the
InputDescriptor.
Summary of change: Define the contents of an InputParameter more clearly in the spec and define
what happens if invalid content is sent to the service.
Last Revision Date: 2 December 2017
Page
10
The OGC Technical Committee Policies & Procedures 05-020r3
Consequences if
not approved:
This is a real interoperability issue.
Clauses affected:
Clause 11.2.1
Other specs
Affected:
Supporting Doc.
Other comments:
Status
Disposition
Other core specifications
Abstract specifications
Best Practices Document
NEW
CR-Form-v3
CHANGE REQUEST
SPS 1.0.0 CR ?
rev
-
Current version:
1.0.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the symbols.
Proposed change affects:
AS
Imp Spec X
Title:
Clarification on notification behaviour
Source:
OWS-5 CITE thread
Best Practices Paper
Work item code:
Category:
Other
Date: 2008-02-06
D
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier
release)
B (Addition of feature),
C (Functional modification of feature)
D (Editorial modification)
Detailed explanations of the above categories can
be found in the TC Policies and Procedures.
Reason for change:
Right now the specification does not clearly define when the service should send
which notification (message) to a task user. Thus it is up to the service to decide
at which point in time to send which message – if at all. This uncertainty is bad
for clients that might expect to receive certain messages during task execution.
Summary of change: Create a separate clause which describes how notification is handled by SPS.
Define which message have to be (or can be) sent when, maybe even
introducing a mechanism for the user to choose between different levels of
verbosity.
Consequences if
not approved:
Clauses affected:
throughout
Last Revision Date: 2 December 2017
Page
11
The OGC Technical Committee Policies & Procedures 05-020r3
Other specs
Affected:
Other core specifications
Abstract specifications
Best Practices Document
Supporting Doc.
Other comments:
Status
Disposition
NEW
CR-Form-v3
CHANGE REQUEST
SPS 1.0.0 CR ?
rev
-
Current version:
1.0.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the symbols.
Proposed change affects:
AS
Imp Spec X
Best Practices Paper
Title:
Clarification on notificationTarget validation
Source:
OWS-5 CITE thread
Work item code:
Category:
Other
Date: 2008-02-06
F
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier
release)
B (Addition of feature),
C (Functional modification of feature)
D (Editorial modification)
Detailed explanations of the above categories can
be found in the TC Policies and Procedures.
Reason for change:
The spec does not define – apart from usual XML validation – how a valid
notificationTarget has to look like. In general, the notificationID can only be
wrong if it is null or an empty String whereas the URL might be checked by being
a valid URL and also by retrieving the WNS Capabilities from that URL.
Summary of change: Define what the SPS has to check with a notificationTarget.
Consequences if
not approved:
Clauses affected:
throughout
Other specs
Affected:
Supporting Doc.
Other comments:
Status
Disposition
Other core specifications
Abstract specifications
Best Practices Document
NEW
Last Revision Date: 2 December 2017
Page
12
The OGC Technical Committee Policies & Procedures 05-020r3
CR-Form-v3
CHANGE REQUEST
SPS 1.0.0 CR ?
rev
-
Current version:
1.0.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the symbols.
Proposed change affects:
AS
Imp Spec X
Best Practices Paper
Title:
Enhancing SensorDefinition semantics
Source:
OWS-5 CITE thread
Work item code:
Category:
Other
Date: 2008-02-06
C
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier
release)
B (Addition of feature),
C (Functional modification of feature)
D (Editorial modification)
Detailed explanations of the above categories can
be found in the TC Policies and Procedures.
Reason for change:
Right now it is not defined where the URL inside a SensorDefiniton can point to.
Usually this would be SensorML, but other formats might also be ok – like TML
or some other format. The service should be able to indicate of what type the
referenced document will be.
Summary of change: Define what the URL inside a SensorDefinition (contained in SPS Contents
section) can point to.
Consequences if
not approved:
Clauses affected:
Clause 12.3.3 + maybe introduction / running example
Other specs
Affected:
Supporting Doc.
Other comments:
Status
Disposition
Other core specifications
Abstract specifications
Best Practices Document
NEW
CR-Form-v3
CHANGE REQUEST
SPS 1.0.0 CR ?
rev
-
Current version:
1.0.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the symbols.
Last Revision Date: 2 December 2017
Page
13
The OGC Technical Committee Policies & Procedures 05-020r3
Proposed change affects:
AS
Imp Spec X
Best Practices Paper
Title:
Introduction of (harmonized) DescribeSensor operation
Source:
OWS-5 CITE thread
Work item code:
Category:
Other
Date: 2008-02-18
C
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier
release)
B (Addition of feature),
C (Functional modification of feature)
D (Editorial modification)
Detailed explanations of the above categories can
be found in the TC Policies and Procedures.
Reason for change:
A sensor's description is provided via the link in the Capabilities. However, it
would be preferred to have a harmonized operation for retrieving a sensor's
description for all SWE services.
Summary of change: Define a DescribeSensor operation (harmonized with other SWE services) as
well.
Consequences if
not approved:
Clauses affected:
Clause 12.3.3 + introduction / running example
Other specs
Affected:
Supporting Doc.
Other comments:
Status
Disposition
Other core specifications
Abstract specifications
Best Practices Document
NEW
CR-Form-v3
CHANGE REQUEST
SPS 1.0.0 CR ?
rev
-
Current version:
1.0.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the symbols.
Proposed change affects:
AS
Imp Spec X
Title:
Optional InputParameter list
Source:
OWS-5 CITE thread
Work item code:
Category:
Best Practices Paper
Other
Date: 2008-02-06
C
Last Revision Date: 2 December 2017
Page
14
The OGC Technical Committee Policies & Procedures 05-020r3
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier
release)
B (Addition of feature),
C (Functional modification of feature)
D (Editorial modification)
Detailed explanations of the above categories can
be found in the TC Policies and Procedures.
Reason for change:
Right now a client has to provide at least one InputParameter in a
GetFeasibility / Submit request for the request to be valid. This is suboptimal in
cases where all parameters are optional and the client does not want to provide
any parameter in the request. Maybe the service even provided default values
for all these parameters so that it is not necessary to change them at all if they
satisfy the needs.
Summary of change: Make InputParameter list optional so that for cases in which there are only
optional parameters one can even create a task without providing any
parameter.
Consequences if
not approved:
Clauses affected:
Clauses 14 + 15 (and maybe running example and introduction)
Other specs
Affected:
Supporting Doc.
Other comments:
Status
Disposition
Other core specifications
Abstract specifications
Best Practices Document
NEW
CR-Form-v3
CHANGE REQUEST
SPS 1.0.0 CR ?
rev
-
Current version:
1.0.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the symbols.
Proposed change affects:
AS
Imp Spec X
Best Practices Paper
Title:
Guidance on description element in Submit operation response
Source:
OWS-5 CITE thread
Work item code:
Category:
Other
Date: 2008-02-06
D
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier
Last Revision Date: 2 December 2017
Page
15
The OGC Technical Committee Policies & Procedures 05-020r3
release)
B (Addition of feature),
C (Functional modification of feature)
D (Editorial modification)
Detailed explanations of the above categories can
be found in the TC Policies and Procedures.
Reason for change:
The description element in the Submit response is optional. Implementers
should have some guidance on when the description is required and when it is
not.
Summary of change: Provide guidance on when a description is required and when it is not.
Consequences if
not approved:
Clauses affected:
Clause 15.3 and subclauses
Other specs
Affected:
Supporting Doc.
Other comments:
Status
Disposition
Other core specifications
Abstract specifications
Best Practices Document
NEW
CR-Form-v3
CHANGE REQUEST
SPS 1.0.0 CR ?
rev
-
Current version:
1.0.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the symbols.
Proposed change affects:
AS
Imp Spec X
Best Practices Paper
Title:
Requirements for validity check of time elements in Submit operation
Source:
OWS-5 CITE thread
Work item code:
Category:
Other
Date: 2008-02-06
D
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier
release)
B (Addition of feature),
C (Functional modification of feature)
D (Editorial modification)
Detailed explanations of the above categories can
be found in the TC Policies and Procedures.
Reason for change:
The spec only uses XML schema validation rules to check that time elements
(estimatedToC, timeFrame and LatestResponse). It should also be specified that
the given time value is after now.
Last Revision Date: 2 December 2017
Page
16
The OGC Technical Committee Policies & Procedures 05-020r3
Summary of change: Define requirements for validity check of time elements in Submit operation.
Consequences if
not approved:
Clauses affected:
Clause 15 and subclauses
Other specs
Affected:
Supporting Doc.
Other comments:
Status
Disposition
Other core specifications
Abstract specifications
Best Practices Document
NEW
CR-Form-v3
CHANGE REQUEST
SPS 1.0.0 CR ?
rev
-
Current version:
1.0.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the symbols.
Proposed change affects:
AS
Imp Spec X
Best Practices Paper
Title:
Durability of alternatives in Submit response
Source:
OWS-5 CITE thread
Work item code:
Category:
Other
Date: 2008-02-06
B
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier
release)
B (Addition of feature),
C (Functional modification of feature)
D (Editorial modification)
Detailed explanations of the above categories can
be found in the TC Policies and Procedures.
Reason for change:
Right now alternatives can just be provided, but the service cannot indicate how
long a set of alternative parameters are guaranteed to result in a confirmed task.
Although that might never be possible, at least a hint for the user could be
provided.
Summary of change: Consider mechanism to include durability indicator for alternatives in Submit
response
Consequences if
not approved:
Clauses affected:
Clause 15 and subclauses
Last Revision Date: 2 December 2017
Page
17
The OGC Technical Committee Policies & Procedures 05-020r3
Other specs
Affected:
Other core specifications
Abstract specifications
Best Practices Document
Supporting Doc.
Other comments:
Status
Disposition
NEW
CR-Form-v3
CHANGE REQUEST
SPS 1.0.0 CR ?
rev
-
Current version:
1.0.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the symbols.
Proposed change affects:
AS
Imp Spec X
Best Practices Paper
Other
Title:
Broaden scope of service type element in DescribeResultAccess response
Source:
OWS-5 CITE thread
Work item code:
Category:
Date: 2008-02-06
D
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier
release)
B (Addition of feature),
C (Functional modification of feature)
D (Editorial modification)
Detailed explanations of the above categories can
be found in the TC Policies and Procedures.
Reason for change:
Right now clause 19. states that only OGC services can be referenced. Although
this is a nice requirement, it should not be mandatory.
Summary of change: Alter description of DescribeResultAccess operation to allow non OGC services
to be referenced in operation response.
Consequences if
not approved:
Clauses affected:
throughout
Other specs
Affected:
Supporting Doc.
Other comments:
Status
Disposition
Other core specifications
Abstract specifications
Best Practices Document
NEW
Last Revision Date: 2 December 2017
Page
18
The OGC Technical Committee Policies & Procedures 05-020r3
CR-Form-v3
CHANGE REQUEST
SPS 1.0.0 CR ?
rev
-
Current version:
1.0.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the symbols.
Proposed change affects:
AS
Imp Spec X
Best Practices Paper
Title:
Improving description of DescribeResultAccess operation
Source:
OWS-5 CITE thread
Work item code:
Category:
Other
Date: 2008-02-06
D
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier
release)
B (Addition of feature),
C (Functional modification of feature)
D (Editorial modification)
Detailed explanations of the above categories can
be found in the TC Policies and Procedures.
Reason for change:
The description of the operation is not sufficient. For example, it is not specified
that an SPS should not return a DRA response containing DataNotAvailable flag
when the request contained a SensorID.
Summary of change: Clearly define the behaviour and meaning of DRA operation, especially which
form the response can have when either SensorID or TaskID is provided in the
request.
Consequences if
not approved:
Clauses affected:
throughout
Other specs
Affected:
Supporting Doc.
Other comments:
Status
Disposition
Other core specifications
Abstract specifications
Best Practices Document
NEW
CR-Form-v3
CHANGE REQUEST
SPS 1.0.0 CR ?
rev
-
Current version:
1.0.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the symbols.
Last Revision Date: 2 December 2017
Page
19
The OGC Technical Committee Policies & Procedures 05-020r3
Proposed change affects:
AS
Imp Spec X
Best Practices Paper
Title:
Clarification of DataNotAvailable in DescribeResultAccess response
Source:
OWS-5 CITE thread
Work item code:
Category:
Other
Date: 2008-02-06
D
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier
release)
B (Addition of feature),
C (Functional modification of feature)
D (Editorial modification)
Detailed explanations of the above categories can
be found in the TC Policies and Procedures.
Reason for change:
Currently the spec lets get to the point, that data which is not yet available shall
result in a DRARR with a list of Services which are designated to store the data.
Correctly a DataNotAvailable? with reason "not yet available" should be
responded if the sensor is still measuring.
Summary of change: Specify the intention of DataNotAvailable in DescribeResultAccess response
more precisely.
Consequences if
not approved:
Clauses affected:
Clause 19.3 and subclauses + running example
Other specs
Affected:
Supporting Doc.
Other comments:
Status
Disposition
Other core specifications
Abstract specifications
Best Practices Document
NEW
Last Revision Date: 2 December 2017
Page
20
Open Geospatial Consortium
Combined SPS CRs from OWS-5 CITE
This document contains the change requests that address issues identified in the OWS-5 CITE
thread for SPS (07-014r3).
CR-Form-v3
CHANGE REQUEST
SPS 1.0.0 CR ?
rev
-
Current version:
1.0.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the symbols.
Proposed change affects:
AS
Imp Spec X
Title:
SweCommon examples incorrect
Source:
OWS-5 CITE thread
Best Practices Paper
Work item code:
Category:
Other
Date: 2008-02-06
F
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier
release)
B (Addition of feature),
C (Functional modification of feature)
D (Editorial modification)
Detailed explanations of the above categories can
be found in the TC Policies and Procedures.
Reason for change:
Some examples in the spec do not seem to be valid according to the current
SweCommon schema baseline. This should be fixed throughout the document.
Summary of change: Go through each example and fix it if necessary.
Consequences if
not approved:
Users / readers of the specification would create incorrect requests / responses.
Clauses affected:
throughout
Other specs
Affected:
Supporting Doc.
Other comments:
Status
Disposition
Other core specifications
Abstract specifications
Best Practices Document
NEW
The OGC Technical Committee Policies & Procedures 05-020r3
CR-Form-v3
CHANGE REQUEST
SPS 1.0.0 CR ?
rev
-
Current version:
1.0.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the symbols.
Proposed change affects:
AS
Imp Spec X
Best Practices Paper
Title:
Definition of valid IDs (sensorID, taskID, feasibilityID)
Source:
OWS-5 CITE thread
Work item code:
Category:
Other
Date: 2008-02-06
D
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier
release)
B (Addition of feature),
C (Functional modification of feature)
D (Editorial modification)
Detailed explanations of the above categories can
be found in the TC Policies and Procedures.
Reason for change:
When creating IDs the schema + specification should make sure that only
meaningful IDs are created by an SPS.
Summary of change: Make sure that an ID is not nillable and that it is a non-empty string.
Consequences if
not approved:
Empty ID fields (or fields with empty strings) would still be valid according to the
schema and spec.
Clauses affected:
Clause 11 (Shared aspects) and subclauses
Other specs
Affected:
Supporting Doc.
Other comments:
Status
Disposition
Other core specifications
Abstract specifications
Best Practices Document
NEW
CR-Form-v3
CHANGE REQUEST
SPS 1.0.0 CR ?
rev
-
Current version:
1.0.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the symbols.
Last Revision Date: 2 December 2017
Page2
The OGC Technical Committee Policies & Procedures 05-020r3
Proposed change affects:
AS
Imp Spec X
Best Practices Paper
Title:
Usage of InvalidParameterValue exception
Source:
OWS-5 CITE thread
Work item code:
Category:
Other
Date: 2008-02-06
F
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier
release)
B (Addition of feature),
C (Functional modification of feature)
D (Editorial modification)
Detailed explanations of the above categories can
be found in the TC Policies and Procedures.
Reason for change:
If the use of the InvalidParameterValue exception is not defined clearly
implementers would not make correct use of the exception + clients do not know
what to expect.
Summary of change: State that each time a mandatory request element is nil or contains an empty
string, this should cause an InvalidParameterValue exception.
Consequences if
not approved:
Usage of InvalidParameterValue exception would be confused by both client and
service developers.
Clauses affected:
Clause 11 (Shared Aspects) or throughout
Other specs
Affected:
Supporting Doc.
Other comments:
Status
Disposition
Other core specifications
Abstract specifications
Best Practices Document
NEW
CR-Form-v3
CHANGE REQUEST
SPS 1.0.0 CR ?
rev
-
Current version:
1.0.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the symbols.
Proposed change affects:
AS
Imp Spec X
Title:
Schema structure in SPS
Source:
OWS-5 CITE thread
Work item code:
Category:
Best Practices Paper
Other
Date: 2008-02-06
D
Last Revision Date: 2 December 2017
Page3
The OGC Technical Committee Policies & Procedures 05-020r3
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier
release)
B (Addition of feature),
C (Functional modification of feature)
D (Editorial modification)
Detailed explanations of the above categories can
be found in the TC Policies and Procedures.
Reason for change:
It would make life easier for client developers if they could reuse global
elements defined in the SPS schema. Also, operation (schema) names and
types contain unnecessary “Request” token. Following rules of object->property>value rules in schema creation would also be nice.
Summary of change: Make Subelements in the SPS schema global where possible and where useful.
For example the DescribeResultAccessRequestResponse could be splitted up.
This would make life easier for developers who can reuse these elements.
Maybe one should make more use of the general element/property/value
approach as well. Also remove unnecessary “Request” token in operation
(schema) names and types.
Consequences if
not approved:
Clauses affected:
Other specs
Affected:
Supporting Doc.
Other comments:
Status
Disposition
Other core specifications
Abstract specifications
Best Practices Document
NEW
CR-Form-v3
CHANGE REQUEST
SPS 1.0.0 CR ?
rev
-
Current version:
1.0.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the symbols.
Proposed change affects:
AS
Imp Spec X
Best Practices Paper
Title:
Improvement of operation request and response descriptions.
Source:
OWS-5 CITE thread
Work item code:
Category:
Other
Date: 2008-02-06
F
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier
release)
Last Revision Date: 2 December 2017
Page4
The OGC Technical Committee Policies & Procedures 05-020r3
B (Addition of feature),
C (Functional modification of feature)
D (Editorial modification)
Detailed explanations of the above categories can
be found in the TC Policies and Procedures.
Reason for change:
Good description for requests and responses is not given directly at the
operation level but rather in the running example. All semantics that are
essential to each operation should be described right there and not in an Annex
or other chapter which might easily be missed.
Summary of change: Provide general description for request / response elements and their meaning
directly instead of in the running example. For example, a thorough description
of the timeFrame parameter in a Submit request can only be found in the
running example.
Consequences if
not approved:
The true (intended) semantics of an operation might be missed by a reader.
Clauses affected:
throughout
Other specs
Affected:
Supporting Doc.
Other comments:
Status
Disposition
Other core specifications
Abstract specifications
Best Practices Document
NEW
CR-Form-v3
CHANGE REQUEST
SPS 1.0.0 CR ?
rev
-
Current version:
1.0.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the symbols.
Proposed change affects:
AS
Imp Spec X
Title:
General task timing approach
Source:
OWS-5 CITE thread
Best Practices Paper
Work item code:
Category:
Other
Date: 2008-02-06
B
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier
release)
B (Addition of feature),
C (Functional modification of feature)
D (Editorial modification)
Detailed explanations of the above categories can
be found in the TC Policies and Procedures.
Last Revision Date: 2 December 2017
Page5
The OGC Technical Committee Policies & Procedures 05-020r3
Reason for change:
It would be good to allow a client to specify a time period for when a task should
be completed. This could be handled on a sensor by sensor basis through the
tasking parameters of the tasking message (i.e. task-start-time and task-endtime as in the 52N Axis SPS), but it might make sense to make it a
standard/optional part of the Submit request (if it's universally appropriate).
Being able to control / parameterize a sensor at a certain time (period), making
sure that a task is completed before a certain point in time and also that data is
available at a certain time plays a role here. For instance, a user might want a
satellite to take a picture of a certain area by tomorrow. The SPS could use the
constraint that the task needs to be completed by tomorrow to determine if the
task is feasible or not, rather than simply queueing up the task and telling the
user that his or her task will be completed by X date/time (assuming the SPS
queues tasking requests).
Summary of change: Consider this new feature in SWG. The GetFeasibility and Submit request might
contain the elements for the new feature (if approved) by default or maybe the
spec could define usage of SweCommon for this.
Consequences if
not approved:
Clauses affected:
Other specs
Affected:
Supporting Doc.
Other comments:
Status
Disposition
Other core specifications
Abstract specifications
Best Practices Document
NEW
CR-Form-v3
CHANGE REQUEST
SPS 1.0.0 CR ?
rev
-
Current version:
1.0.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the symbols.
Proposed change affects:
AS
Imp Spec X
Title:
Handling of submitted tasks
Source:
OWS-5 CITE thread
Best Practices Paper
Work item code:
Category:
Other
Date: 2008-02-06
B
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier
release)
B (Addition of feature),
C (Functional modification of feature)
D (Editorial modification)
Detailed explanations of the above categories can
Last Revision Date: 2 December 2017
Page6
The OGC Technical Committee Policies & Procedures 05-020r3
be found in the TC Policies and Procedures.
Reason for change:
We do not have any parameter in the sensors interface with which a client could
indicate when the task should take place. Thus it is up to the sensor to decide
when it will be performed. The apparent assumption that a task takes place
directly after it was submitted is not guaranteed to hold true in all cases. Think
for example of a simulation encapsulated behind an SPS: if ten tasks are
submitted, the simulation could put all of them in a queue and work on them one
after the other. A stupid sensor on the other hand might only be capable of
waiting for a task, performing it, ignoring all Submit requests during task
execution and then waiting again. These are all feasible behaviour for sensors
facaded by an SPS. The question is if the SPS interface should indicate how a
sensor handles tasks.
Summary of change: Consider this new feature in SWG. Maybe this could be done by adding an
attribute or element to each SensorOffering in the Capabilities of the SPS that
just takes a code. The OGC (or some other domain) could then create a list of
possible behavior with a code for each.
Consequences if
not approved:
Task handling by the service will still be a guess by the client. It would be quite
hard to define any policies / guarantees between service and client if the task
handling was not defined.
Clauses affected:
throughout
Other specs
Affected:
Supporting Doc.
Other comments:
Status
Disposition
Other core specifications
Abstract specifications
Best Practices Document
NEW
CR-Form-v3
CHANGE REQUEST
SPS 1.0.0 CR ?
rev
-
Current version:
1.0.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the symbols.
Proposed change affects:
AS
Imp Spec X
Best Practices Paper
Other
Title:
Guarantee match between procedure IDs and ID contained in sensor description
document.
Source:
OWS-5 CITE thread
Work item code:
Category:
Date: 2008-02-11
B
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier
release)
B (Addition of feature),
Last Revision Date: 2 December 2017
Page7
The OGC Technical Committee Policies & Procedures 05-020r3
C (Functional modification of feature)
D (Editorial modification)
Detailed explanations of the above categories can
be found in the TC Policies and Procedures.
Reason for change:
Right now it is up to the provider of the service how a certain sensor is identified
at his service. Thus, the link between a sensor and its sensor description (either
SensorML or TML) is implicit by the grouping of a SensorID and the link to the
sensors description in a SensorOffering.
But in cases where the same sensor is registered at multiple services (maybe at
different service types, so for example at SOS, SAS and SPS) one does not
directly see that the ID of a specific sensor actually means the same. Only by
checking an ID that is possibly contained in the sensor description and
comparing those one could derive the information that some sensor IDs at
multiple services are actually identifying the same sensor. So it would be
preferred that both the sensor description (we will write a Change Request for
SensorML to make sure that the way to include such an identifier is specified in
SensorML) and the service offering both use the same identifier.
Summary of change: Specify that a sensor’s ID has to be the same as the one contained in its sensor
description.
Consequences if
not approved:
Being able to clearly identify sensors across service boundaries would still not be
possible.
Clauses affected:
Throughout (the introductory clauses as well as the description of the Contents
section)
Other specs
Affected:
Supporting Doc.
Other comments:
Status
Disposition
Other core specifications
Abstract specifications
Best Practices Document
NEW
CR-Form-v3
CHANGE REQUEST
SPS 1.0.0 CR ?
rev
-
Current version:
1.0.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the symbols.
Proposed change affects:
AS
Imp Spec X
Title:
Default value(s) in InputDescriptors
Source:
OWS-5 CITE thread
Best Practices Paper
Work item code:
Category:
Other
Date: 2008-02-06
B
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier
Last Revision Date: 2 December 2017
Page8
The OGC Technical Committee Policies & Procedures 05-020r3
release)
B (Addition of feature),
C (Functional modification of feature)
D (Editorial modification)
Detailed explanations of the above categories can
be found in the TC Policies and Procedures.
Reason for change:
Oftentimes it might be easier for a service to define a default value for a
parameter and the client might just agree with it or at least have an idea of what
value could be provided to the service. So it makes sense to define how a
default value can be put in an InputDescriptor.
Summary of change: Define how default values can be put in an InputDescriptor. If SweCommon is
used, this could be done by simply providing a value in the responding
SweCommon element.
Consequences if
not approved:
Clauses affected:
Clause 11.2.1
Other specs
Affected:
Supporting Doc.
Other comments:
Status
Disposition
Other core specifications
Abstract specifications
Best Practices Document
NEW
CR-Form-v3
CHANGE REQUEST
SPS 1.0.0 CR ?
rev
-
Current version:
1.0.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the symbols.
Proposed change affects:
AS
Imp Spec X
Best Practices Paper
Title:
Clarification on restriction element in InputDescriptor
Source:
OWS-5 CITE thread
Work item code:
Category:
Other
Date: 2008-02-06
D
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier
release)
B (Addition of feature),
C (Functional modification of feature)
D (Editorial modification)
Detailed explanations of the above categories can
be found in the TC Policies and Procedures.
Last Revision Date: 2 December 2017
Page9
The OGC Technical Committee Policies & Procedures 05-020r3
Reason for change:
It is not clearly defined when the restriction element in an InputDescriptor should
be used exactly. In the beginning of OWS-3 SweCommon did not have
constraints on its simple types, now it has. So the use of the restriction element
is no longer needed in every case.
Summary of change: Clearly define usage of restriction element in an InputDescriptor and give an
example when it can be applied.
Consequences if
not approved:
Clauses affected:
Clause 11.2.1
Other specs
Affected:
Supporting Doc.
Other comments:
Status
Disposition
Other core specifications
Abstract specifications
Best Practices Document
NEW
CR-Form-v3
CHANGE REQUEST
SPS 1.0.0 CR ?
rev
-
Current version:
1.0.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the symbols.
Proposed change affects:
AS
Imp Spec X
Best Practices Paper
Title:
Clarification of InputParameter content encoding / creation
Source:
OWS-5 CITE thread
Work item code:
Category:
Other
Date: 2008-02-06
F
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier
release)
B (Addition of feature),
C (Functional modification of feature)
D (Editorial modification)
Detailed explanations of the above categories can
be found in the TC Policies and Procedures.
Reason for change:
Right now only the examples (and even those are not 100% correct) show how
an InputParameter should be created based upon an InputDescriptor. When
describing the InputParameter element, the spec should also describe in detail
how the content of this element is expected to be derived from the
InputDescriptor.
Summary of change: Define the contents of an InputParameter more clearly in the spec and define
what happens if invalid content is sent to the service.
Last Revision Date: 2 December 2017
Page
10
The OGC Technical Committee Policies & Procedures 05-020r3
Consequences if
not approved:
This is a real interoperability issue.
Clauses affected:
Clause 11.2.1
Other specs
Affected:
Supporting Doc.
Other comments:
Status
Disposition
Other core specifications
Abstract specifications
Best Practices Document
NEW
CR-Form-v3
CHANGE REQUEST
SPS 1.0.0 CR ?
rev
-
Current version:
1.0.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the symbols.
Proposed change affects:
AS
Imp Spec X
Title:
Clarification on notification behaviour
Source:
OWS-5 CITE thread
Best Practices Paper
Work item code:
Category:
Other
Date: 2008-02-06
D
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier
release)
B (Addition of feature),
C (Functional modification of feature)
D (Editorial modification)
Detailed explanations of the above categories can
be found in the TC Policies and Procedures.
Reason for change:
Right now the specification does not clearly define when the service should send
which notification (message) to a task user. Thus it is up to the service to decide
at which point in time to send which message – if at all. This uncertainty is bad
for clients that might expect to receive certain messages during task execution.
Summary of change: Create a separate clause which describes how notification is handled by SPS.
Define which message have to be (or can be) sent when, maybe even
introducing a mechanism for the user to choose between different levels of
verbosity.
Consequences if
not approved:
Clauses affected:
throughout
Last Revision Date: 2 December 2017
Page
11
The OGC Technical Committee Policies & Procedures 05-020r3
Other specs
Affected:
Other core specifications
Abstract specifications
Best Practices Document
Supporting Doc.
Other comments:
Status
Disposition
NEW
CR-Form-v3
CHANGE REQUEST
SPS 1.0.0 CR ?
rev
-
Current version:
1.0.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the symbols.
Proposed change affects:
AS
Imp Spec X
Best Practices Paper
Title:
Clarification on notificationTarget validation
Source:
OWS-5 CITE thread
Work item code:
Category:
Other
Date: 2008-02-06
F
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier
release)
B (Addition of feature),
C (Functional modification of feature)
D (Editorial modification)
Detailed explanations of the above categories can
be found in the TC Policies and Procedures.
Reason for change:
The spec does not define – apart from usual XML validation – how a valid
notificationTarget has to look like. In general, the notificationID can only be
wrong if it is null or an empty String whereas the URL might be checked by being
a valid URL and also by retrieving the WNS Capabilities from that URL.
Summary of change: Define what the SPS has to check with a notificationTarget.
Consequences if
not approved:
Clauses affected:
throughout
Other specs
Affected:
Supporting Doc.
Other comments:
Status
Disposition
Other core specifications
Abstract specifications
Best Practices Document
NEW
Last Revision Date: 2 December 2017
Page
12
The OGC Technical Committee Policies & Procedures 05-020r3
CR-Form-v3
CHANGE REQUEST
SPS 1.0.0 CR ?
rev
-
Current version:
1.0.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the symbols.
Proposed change affects:
AS
Imp Spec X
Best Practices Paper
Title:
Enhancing SensorDefinition semantics
Source:
OWS-5 CITE thread
Work item code:
Category:
Other
Date: 2008-02-06
C
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier
release)
B (Addition of feature),
C (Functional modification of feature)
D (Editorial modification)
Detailed explanations of the above categories can
be found in the TC Policies and Procedures.
Reason for change:
Right now it is not defined where the URL inside a SensorDefiniton can point to.
Usually this would be SensorML, but other formats might also be ok – like TML
or some other format. The service should be able to indicate of what type the
referenced document will be.
Summary of change: Define what the URL inside a SensorDefinition (contained in SPS Contents
section) can point to.
Consequences if
not approved:
Clauses affected:
Clause 12.3.3 + maybe introduction / running example
Other specs
Affected:
Supporting Doc.
Other comments:
Status
Disposition
Other core specifications
Abstract specifications
Best Practices Document
NEW
CR-Form-v3
CHANGE REQUEST
SPS 1.0.0 CR ?
rev
-
Current version:
1.0.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the symbols.
Last Revision Date: 2 December 2017
Page
13
The OGC Technical Committee Policies & Procedures 05-020r3
Proposed change affects:
AS
Imp Spec X
Best Practices Paper
Title:
Introduction of (harmonized) DescribeSensor operation
Source:
OWS-5 CITE thread
Work item code:
Category:
Other
Date: 2008-02-18
C
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier
release)
B (Addition of feature),
C (Functional modification of feature)
D (Editorial modification)
Detailed explanations of the above categories can
be found in the TC Policies and Procedures.
Reason for change:
A sensor's description is provided via the link in the Capabilities. However, it
would be preferred to have a harmonized operation for retrieving a sensor's
description for all SWE services.
Summary of change: Define a DescribeSensor operation (harmonized with other SWE services) as
well.
Consequences if
not approved:
Clauses affected:
Clause 12.3.3 + introduction / running example
Other specs
Affected:
Supporting Doc.
Other comments:
Status
Disposition
Other core specifications
Abstract specifications
Best Practices Document
NEW
CR-Form-v3
CHANGE REQUEST
SPS 1.0.0 CR ?
rev
-
Current version:
1.0.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the symbols.
Proposed change affects:
AS
Imp Spec X
Title:
Optional InputParameter list
Source:
OWS-5 CITE thread
Work item code:
Category:
Best Practices Paper
Other
Date: 2008-02-06
C
Last Revision Date: 2 December 2017
Page
14
The OGC Technical Committee Policies & Procedures 05-020r3
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier
release)
B (Addition of feature),
C (Functional modification of feature)
D (Editorial modification)
Detailed explanations of the above categories can
be found in the TC Policies and Procedures.
Reason for change:
Right now a client has to provide at least one InputParameter in a
GetFeasibility / Submit request for the request to be valid. This is suboptimal in
cases where all parameters are optional and the client does not want to provide
any parameter in the request. Maybe the service even provided default values
for all these parameters so that it is not necessary to change them at all if they
satisfy the needs.
Summary of change: Make InputParameter list optional so that for cases in which there are only
optional parameters one can even create a task without providing any
parameter.
Consequences if
not approved:
Clauses affected:
Clauses 14 + 15 (and maybe running example and introduction)
Other specs
Affected:
Supporting Doc.
Other comments:
Status
Disposition
Other core specifications
Abstract specifications
Best Practices Document
NEW
CR-Form-v3
CHANGE REQUEST
SPS 1.0.0 CR ?
rev
-
Current version:
1.0.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the symbols.
Proposed change affects:
AS
Imp Spec X
Best Practices Paper
Title:
Guidance on description element in Submit operation response
Source:
OWS-5 CITE thread
Work item code:
Category:
Other
Date: 2008-02-06
D
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier
Last Revision Date: 2 December 2017
Page
15
The OGC Technical Committee Policies & Procedures 05-020r3
release)
B (Addition of feature),
C (Functional modification of feature)
D (Editorial modification)
Detailed explanations of the above categories can
be found in the TC Policies and Procedures.
Reason for change:
The description element in the Submit response is optional. Implementers
should have some guidance on when the description is required and when it is
not.
Summary of change: Provide guidance on when a description is required and when it is not.
Consequences if
not approved:
Clauses affected:
Clause 15.3 and subclauses
Other specs
Affected:
Supporting Doc.
Other comments:
Status
Disposition
Other core specifications
Abstract specifications
Best Practices Document
NEW
CR-Form-v3
CHANGE REQUEST
SPS 1.0.0 CR ?
rev
-
Current version:
1.0.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the symbols.
Proposed change affects:
AS
Imp Spec X
Best Practices Paper
Title:
Requirements for validity check of time elements in Submit operation
Source:
OWS-5 CITE thread
Work item code:
Category:
Other
Date: 2008-02-06
D
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier
release)
B (Addition of feature),
C (Functional modification of feature)
D (Editorial modification)
Detailed explanations of the above categories can
be found in the TC Policies and Procedures.
Reason for change:
The spec only uses XML schema validation rules to check that time elements
(estimatedToC, timeFrame and LatestResponse). It should also be specified that
the given time value is after now.
Last Revision Date: 2 December 2017
Page
16
The OGC Technical Committee Policies & Procedures 05-020r3
Summary of change: Define requirements for validity check of time elements in Submit operation.
Consequences if
not approved:
Clauses affected:
Clause 15 and subclauses
Other specs
Affected:
Supporting Doc.
Other comments:
Status
Disposition
Other core specifications
Abstract specifications
Best Practices Document
NEW
CR-Form-v3
CHANGE REQUEST
SPS 1.0.0 CR ?
rev
-
Current version:
1.0.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the symbols.
Proposed change affects:
AS
Imp Spec X
Best Practices Paper
Title:
Durability of alternatives in Submit response
Source:
OWS-5 CITE thread
Work item code:
Category:
Other
Date: 2008-02-06
B
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier
release)
B (Addition of feature),
C (Functional modification of feature)
D (Editorial modification)
Detailed explanations of the above categories can
be found in the TC Policies and Procedures.
Reason for change:
Right now alternatives can just be provided, but the service cannot indicate how
long a set of alternative parameters are guaranteed to result in a confirmed task.
Although that might never be possible, at least a hint for the user could be
provided.
Summary of change: Consider mechanism to include durability indicator for alternatives in Submit
response
Consequences if
not approved:
Clauses affected:
Clause 15 and subclauses
Last Revision Date: 2 December 2017
Page
17
The OGC Technical Committee Policies & Procedures 05-020r3
Other specs
Affected:
Other core specifications
Abstract specifications
Best Practices Document
Supporting Doc.
Other comments:
Status
Disposition
NEW
CR-Form-v3
CHANGE REQUEST
SPS 1.0.0 CR ?
rev
-
Current version:
1.0.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the symbols.
Proposed change affects:
AS
Imp Spec X
Best Practices Paper
Other
Title:
Broaden scope of service type element in DescribeResultAccess response
Source:
OWS-5 CITE thread
Work item code:
Category:
Date: 2008-02-06
D
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier
release)
B (Addition of feature),
C (Functional modification of feature)
D (Editorial modification)
Detailed explanations of the above categories can
be found in the TC Policies and Procedures.
Reason for change:
Right now clause 19. states that only OGC services can be referenced. Although
this is a nice requirement, it should not be mandatory.
Summary of change: Alter description of DescribeResultAccess operation to allow non OGC services
to be referenced in operation response.
Consequences if
not approved:
Clauses affected:
throughout
Other specs
Affected:
Supporting Doc.
Other comments:
Status
Disposition
Other core specifications
Abstract specifications
Best Practices Document
NEW
Last Revision Date: 2 December 2017
Page
18
The OGC Technical Committee Policies & Procedures 05-020r3
CR-Form-v3
CHANGE REQUEST
SPS 1.0.0 CR ?
rev
-
Current version:
1.0.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the symbols.
Proposed change affects:
AS
Imp Spec X
Best Practices Paper
Title:
Improving description of DescribeResultAccess operation
Source:
OWS-5 CITE thread
Work item code:
Category:
Other
Date: 2008-02-06
D
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier
release)
B (Addition of feature),
C (Functional modification of feature)
D (Editorial modification)
Detailed explanations of the above categories can
be found in the TC Policies and Procedures.
Reason for change:
The description of the operation is not sufficient. For example, it is not specified
that an SPS should not return a DRA response containing DataNotAvailable flag
when the request contained a SensorID.
Summary of change: Clearly define the behaviour and meaning of DRA operation, especially which
form the response can have when either SensorID or TaskID is provided in the
request.
Consequences if
not approved:
Clauses affected:
throughout
Other specs
Affected:
Supporting Doc.
Other comments:
Status
Disposition
Other core specifications
Abstract specifications
Best Practices Document
NEW
CR-Form-v3
CHANGE REQUEST
SPS 1.0.0 CR ?
rev
-
Current version:
1.0.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the symbols.
Last Revision Date: 2 December 2017
Page
19
The OGC Technical Committee Policies & Procedures 05-020r3
Proposed change affects:
AS
Imp Spec X
Best Practices Paper
Title:
Clarification of DataNotAvailable in DescribeResultAccess response
Source:
OWS-5 CITE thread
Work item code:
Category:
Other
Date: 2008-02-06
D
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier
release)
B (Addition of feature),
C (Functional modification of feature)
D (Editorial modification)
Detailed explanations of the above categories can
be found in the TC Policies and Procedures.
Reason for change:
Currently the spec lets get to the point, that data which is not yet available shall
result in a DRARR with a list of Services which are designated to store the data.
Correctly a DataNotAvailable? with reason "not yet available" should be
responded if the sensor is still measuring.
Summary of change: Specify the intention of DataNotAvailable in DescribeResultAccess response
more precisely.
Consequences if
not approved:
Clauses affected:
Clause 19.3 and subclauses + running example
Other specs
Affected:
Supporting Doc.
Other comments:
Status
Disposition
Other core specifications
Abstract specifications
Best Practices Document
NEW
Last Revision Date: 2 December 2017
Page
20