• Tidak ada hasil yang ditemukan

Change Requests | OGC

N/A
N/A
Protected

Academic year: 2017

Membagikan "Change Requests | OGC"

Copied!
2
0
0

Teks penuh

(1)

All Fields marked with

*

are mandatory.

Name:

*

Jolyon Martin

Organization:

*

ESA

Email:

*

[email protected]

Document

Name/Version:

*

Web Services Common Standard / 1.2

OGC Project

Document:

*

06-121r8

If this is a revision of a previous submission and you have a Change Request Number, then check here:

Enter the CR number here:

Enter the Revsion Number that you are revising here:

Title:

*

SOAP Version

Source:

*

http://wiki.services.eoportal.org/tiki-index.php?page=HMA-FO+OWS+Common+1.2+review

Work item code:

Category:

*

Reason for

change:

*

Clauses 8.7 and 11.8 are about SOAP bindings of services.

Clause 8.7 states: "Specific OWS servers may optionally implement SOAP version 1.2 transfers of all operation requests as specified in Subclause 11.8."

Clause 11.8 states: "Specific OWS specifications shall specify that servers may optionally implement SOAP 1.2 transfer of all operation requests and responses, using the same XML encodings as specified for use with HTTP POST."

While the first statement would express that SOAP v1.2 is not required by a serivce's SOAP binding, in combination with the second statement it becomes mandatory. While the second statement does not seem to prohibit SOAP v1.1, it clearly states that at least a SOAP binding based upon SOAP v1.2 is required by a service.

The question is if such a requirement is necessary. It would also be possible to say that the SOAP version should not be specified by the standard (OWS Common) itself but that it rather should be chosen by an actual implementation. Some existing standards and applications are designed to use SOAP 1.1 while others prefer 1.2, others may support both. For example, the INSPIRE directive seems to rely on SOAP v1.1 in its current form though the switch to 1.2 is foreseen as soon as WS-I BasicProfile 2.0 will change from draft to final version (see clause 5.1 in the INSPIRE Network Services SOAP Framework

-http://inspire.jrc.ec.europa.eu/reports/ImplementingRules/network/INSPIRE_NETWORK_SERVICES_SOAP_Framework.pdf)

Summary of

change:

*

OWS Common should be agnostic to the SOAP version so that implementations may choose freely.

Consequences if

not approved:

(2)

Clauses affected:

*

Clauses 8.7 and 11.8

Additional

Documents

affected:

Supporting

Documentation:

http://wiki.services.eoportal.org/tiki-index.php?page=HMA-FO+OWS+Common+1.2+review

Comments:

Status:

Disposition:

Referensi

Dokumen terkait

The “opt” schema provides the description of metadata common to all EO Products derived from optical satellite based remote sensing. It describes the same fields as the “eop”

b) Test method: Verify that the EOMaskInformation ExtrinsicObject and its slots are instantiated with the correct cardinality, as defined in Table 7.. slots correspond

 Temporal reference systems modelled after ISO 19108 now need to inherit correctly from ISO 19111 classes (as per ISO 19111:2007)  Support is required for abstract

An alternative location scheme is to use linearly referenced locations, where a location is specified as being at a certain distance along (and perhaps offset from) a linear

This principle extends the CityGML topological structure for LandUse (page 94 of CityGML specifications) to other classes at surface level which as per this proposal would be

While this could just be handled internally within the implementation, there is a question as to whether allowable roles should be disclosed in the Capabilities. Consequences if

A number of styling requirements were identified as a result, including enhancement to polygon fill styles. The solution proposed for these fill styles was implemented in one

For example, in a notification that contains a CapabilitiesChanged event as message, the service identifier could be used to indicate which service's Capabilities document