[Requests] OGC Calls for Comment on revision to OGC Web Services Common Standard

Roberto Lucchi roberto.lucchi at jrc.ec.europa.eu
Wed May 20 10:54:32 EDT 2009


PART A

 

 

1. Evaluator:

Roberto Lucchi 

European Commission, DG Joint Research Centre, Institute for Environment and
Sustainability, Spatial Data Infrastructures Unit T.P. 262, I-21020 Ispra
(VA), Italy 

Tel: +39 0332 78 5325        Fax: +39 0332 78 6325

e-mail: roberto.lucchi at jrc.ec.europa.eu

SDI Unit: http://sdi.jrc.it/

IES Institute: http://ies.jrc.ec.europa.eu/

JRC: http://www.jrc.ec.europa.eu/

 

 

2. Submission: [OpenGIS Project Document Number, Name]

Reference number of this document: OGC 06-121r7

Candidate Revision: OGC Web Services Common 1.2

Version 1.2.0

 

 

PART B

 

 

1. Requirement: [General, #] 

Maybe useful list the set of suggested technologies and their version in the
same place where the SOAP version is defined, currently related technologies
are addressed in the XML encoding chapter, see section  11.8.

 

2. Implementation Specification Section number: [General, #]

Section 9.2.4 (minimal abilities for the SOAP encoding)

Section 8.7

Section 11.8

 

3. Criticality: [Major, Minor, Editorial, etc.]

 

4. Comments/justifications for changes: [Comments]

INSPIRE SOAP Framework document, whose aim is to support member States in
identifying solutions for the INSPIRE Network Services implementation (NOT a
legally binding document), proposes in its first version the usage of SOAP
version 1.1 following coherently the set of technologies defined in the WS-I
1.2 basic profile (a corresponding ISO standard is already available for
WS-I version 1.1). It would be in my opinion good spend some words for
justifying the rational behind recommended technologies; maybe some OWS
testbeds on SOAP are immediately providing reusable considerations. 

Other differences due to the usage of WS-I: 

a) the exception message slightly differs from the structure proposed in
Section 8.7., 

b) WS-I recommends the XML UTF-8 encoding; I haven't seen details on this
aspect in OWS-common. 

Regarding these differences I also wonder whether would be possible define a
second SOAP binding based on a different SOAP version.

 

Concerning Section 11.8, i wonder if the acceptLanguage optional parameter
can be seen instead as an optional element, also because: 

a) services without supported languages capabilities section are considered
trivially compliant,

b) there might be the case where cascading services would potentially need
to know the used language. 

Currently the INSPIRE SOAP framework considers the language as an element of
the SOAP header.

 

- - - 

 

1. Requirement: [General, #] 

Language codes, maybe worth allowing alternatives at the proposed IETF RFC
4646 encoding. A solution might be put a reference at the used language
coding (e.g. IETF RFC 4646, ISO 639-2). 

This change is partially related with the LanguageString type definition,
see figure 4.

 

2. Implementation Specification Section number: [General, #]

Table 3

 

3. Criticality: [Major, Minor, Editorial, etc.]

Minor (potentially major)

 

4. Comments/justifications for changes: [Comments]

I'd like point out that the proposal for implementing the language code in
INSPIRE network services is the following: 3-letter code as described in ISO
639-2. 

 

- - - 

 

1. Requirement: [General, #] 

Resources and getRresourceByid

 

2. Implementation Specification Section number: [General, #]

Section 9.3

 

3. Criticality: [Major, Minor, Editorial, etc.]

Minor

 

4. Comments/justifications for changes: [Comments]

I think the resource and its reference (ResourceID) might be used to support
the "store result" boolean attribute available in the WPS execute (a similar
option i think appears also in WCS). More precisely when the result of an
execute operation is stored it is actually referenced using an URL pointing
to the execute result. For various reasons, including the management of such
results and the access control, it would be appropriate provide access at
the stored result (meaning a new accessible resource) through a standardized
interface rather than an url. Therefore i would propose to add this scenario
in the examples: WPS.execute invocation with store="true" that returns,
rather than a URL, a ResourceID.

 

--- - -- - - - 

 

 

Roberto Lucchi 
European Commission, DG Joint Research Centre, Institute for Environment and
Sustainability, Spatial Data Infrastructures Unit T.P. 262, I-21020 Ispra
(VA), Italy 

Tel: +39 0332 78 5325        Fax: +39 0332 78 6325
e-mail: roberto.lucchi at jrc.ec.europa.eu

SDI Unit:  <http://sdi.jrc.it/> http://sdi.jrc.it/
IES Institute:  <http://ies.jrc.ec.europa.eu/> http://ies.jrc.ec.europa.eu/
JRC:  <http://www.jrc.ec.europa.eu/> http://www.jrc.ec.europa.eu/

 

The views expressed are purely those of the writer and may not in any
circumstances be regarded as stating an official position of the European
Commission.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opengeospatial.org/pipermail/requests/attachments/20090520/59a9401a/attachment-0001.htm 


More information about the Requests mailing list