Open Geospatial Consortium
Document
OGC 08-020
CR-Form-v3
CHANGE REQUEST
SPS 1.0 CR ? rev - Current version: 1.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 Impl Stand X Best Practices Paper Other
Title: Harmonization with SWE Common and Operations/Interactions Update
Source: Ingo Simonis, Alexandre Robin, Johannes Echterhoff
Work item code: Date: 2008-02-22
Category: C (Add needed information)
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)
Reason for change: First, SPS is not fully harmonized with SWE Common, but uses a proprietary approach to define parameters and tasking arguments. Second, the
interaction patterns use proprietary solutions. Third, the operations shall be revised to provide more functionality
Summary of change: Modify the parameter definitions to use SWE Common, update the operations message payload, switch protocol binding to SOAP on HTTP, integrate OASIS WS-Notification standard. Changes to both text and schema are required.
Consequences if
not approved:
The SPS will not fit into the SWE Suite of services. There is considerably more effort to implement the SWE Suite if not harmonized. Understanding of the SWE models is complicated. Required functionalities are not supported.
OGC 08-020
Clauses affected: 6-20
Other specs Other core specifications
Affected: Abstract specifications
X Best Practices Papers SPS EO Profile OGC 07-008
Supporting Doc.
Other comments:
Status NEW
Disposition
Change Request Description
This change request requests rather extensive changes to the existing SPS v1.0 standard.
In detail, the following aspects shall be resolved:
1. Integration of the SOAP on HTTP binding to facilitate the usage of OASIS specifications WS-Notification, WS-Addressing, WS-Topics
2. Change of the communication patterns: Remove the notification interaction approach proprietary to SPS and replace it with elements defined in the OASIS specifications WS-Notification in combination with WS-Addressing and WS-Topic.
a. Remove the NotificationTarget element from the various operation definitions b. Describe usage of OASIS Subscribe operation to make
i. notifications available to users,
ii. allow n-users to subscribe to a single task
c. Define Topics users can subscribe to. Those topics shall cover the typical SPS alert messages like TASK_STARTED, TASK_DELAYED, as described in the current specification. Identify and add additional topics if necessary.
d. Define the topics in the capabilities of the service, i.e. change the Capabilities document content definition
e.
Add section in the text about how to implement notification system based on OASIS WS-N by implementing the NotificationProducer and SubscriptionManager interface.f.
Add a section in the text to describe the use of wsnt:UseRaw policy3. Harmonization with SWE Common: The parameter settings in both requests and responses
OGC 08-020
shall use SWE Common instead of the proprietary SPS approach.
4. SPS shall inform more detailed about the status of individual tasking requests.
5. Identify the operations that shall support asynchronous communication between the client and the user. Probably all operations shall support asynchronous communication.
6. Regroup DescribeSubmit and DescribeGetFeasibility into DescribeTasking with different sections. Extract common tasking request parameters (for both feasibility and submit), add a group for additional parameters for GetFeasibility and Submit, and two groups of response parameters for GetFeasibility and Submit. GetFeasibility and Submit requests shall also be changed slightly to split tasking parameters from additional parameters.
7. Simplify SPS to use only SWE Common instead of nested Parameters. Nesting of
Parameters is required by complex implementation like the EO SPS. SWE Common already provides full recursivity. This also implies that messages could be sent in XML, ASCII or binary encoding
8. Add section in capabilities document that describes the supported encodings
9. The DescribeResultAccess shall be revised to account for cases where the data cannot be obtained directly but through another service. In such a case, there is no real immediate “result”, but rather a suggestion to go to another service to finish the workflow.
10. Use OWS Common ReferenceGroup in DescribeResultAccess to provide a mechanism that supports handling of results in multiple parts as well as multiple results
11. Add a section about SPS tasking pure actuators
