OpenGIS
©
Specification OGC 04-094
Copyright © Open Geospatial Consortium, Inc 2005
14
XML. This means that SOAP provides a way to communicate between applications running on different operating systems, with different technologies and programming
languages.
A SOAP message is an ordinary XML document containing the following elements:
a A required Envelope element that identifies the XML document as a SOAP message b An optional Header element that contains header information
c A required Body element that contains call and response information d An optional Fault element that provides information about errors that occurred while
processing the message
All the elements above are declared in the default namespace for the SOAP envelope:
http:www.w3.org200305soap-envelope
and the default namespace for SOAP encoding and data types is:
http:www.w3.org200305soap-encoding
The SOAP specification defines a number of syntax rules. Among the most important are:
e A SOAP message shall be encoded using XML f A SOAP message shall use the SOAP Envelope namespace
g A SOAP message shall use the SOAP Encoding namespace h A SOAP message shall not contain a DTD reference
i A SOAP message shall not contain XML Processing Instructions
The following XML fragment illustrates a skeleton SOAP message:
?xml version=1.0? soap:Envelope
xmlns:soap=http:www.w3.org200305soap-envelope soap:encodingStyle=http:www.w3.org200305soap-encoding
soap:Header ...
... soap:Header
soap:Body ...
... soap:Fault
... ...
soap:Fault soap:Body
soap:Envelope
OpenGIS
©
Specification OGC 04-094
Copyright © Open Geospatial Consortium, Inc 2005
15
A client may send WFS requests to a compatible server using the body of a SOAP envelope. The client simply encodes the WFS request as the content of the soap:Body
element in the request message.
The WFS may then response by generating a SOAP message where the response to the client’s request is the content of the soap:Body element.
In the event the an exception is encountered while processing a WFS request encoded in a SOAP envelope, the web feature service must generate a SOAP response message
where the content of the soap:Body element is a soap:Fault element. The following skeleton XML fragment must be used when generating the soap:Body
element in the event that a WFS encounters an exception:
soap:Body soap:Fault
soap:faultcodesoap:Serversoap:faultode soap:faultstringA server exception was encountered.soap:faultstring
soap:faultactorhttp:www.url_of_WFS_server.comsoap:faultactor soap:detail
ows:ExceptionReport …
ows:ExpetionReport soap:detail
soap:Fault soap:Body
The soap:faultcode element must have the content soap:Server indicating that this is a server exception. The soap:faultstring element must have the content “Server
exception was encountered.”. This fixed string is used since the details of the exception will be specified in the soap:detail element using an ows:ExceptionRecport
element as defined in document [15].
The soap:detail element must contain an ows:ExceptionReport element detailing the specific exception that the server encountered.
The use of the soap:Header element is not discussed in this version of this specification.
7 Common elements
7.1 Feature and Element Identifiers
This document assumes that every feature instance that a particular WFS implementation can operate upon is uniquely identifiable. That is to say, when a WFS implementation
reports a feature identifier for a feature instance, that feature identifier is unique to the server and can be used to repeatedly reference the same feature instance assuming it has
not been deleted. It is further assumed that a feature identifier is encoded as described in the OpenGIS
®
Filter Encoding Implementation Specification [3]. A feature identifier can be used wherever a feature reference is required.
OpenGIS
©
Specification OGC 04-094
Copyright © Open Geospatial Consortium, Inc 2005
16
This document further assumes that if a particular WFS implementation supports the GetGmlObject operation, each element that the WFS can operate on is uniquely
identifiable. That is to say, when a WFS implementation reports an element identifier for an element, that identifier is unique to the server and can be user to reference the same
element assuming it has not been deleted. Element identifiers are encoded as described in the OpenGIS
®
Filter Encoding Implementation Specification[3]. An element identifier can be used wherever a element reference is required.
Note that the feature identifier element used in version 1.0.0 of OpenGIS
®
Filter Encoding Implementation Specification and version 1.0.0 of this specification has been
deprecated in favor of an element identifier element that is used as an identifier for both features and elements. See clause 11 Element Identifiers in [3] for details.
For reference purposes, the XML Schema fragment that defines identifier elements is copied from the filter encoding specification:
xsd:element name=_Id type=ogc:AbstractIdType abstract=true xsd:element name=FeatureId type=ogc:FeatureIdType substitutionGroup=ogc:_Id
xsd:element name=GmlObjectId type=ogc:GmlObjectIdType substitutionGroup=ogc:_Id
xsd:complexType name=AbstractIdType abstract=true xsd:complexType name=FeatureIdType
xsd:complexContent xsd:extension base=ogc:AbstractIdType
xsd:attribute name=fid type=xsd:ID use=required
xsd:extension xsd:complexContent
xsd:complexType xsd:complexType name=GmlObjectIdType
xsd:complexContent xsd:extension base=ogc:AbstractIdType
xsd:attribute ref=gml:id use=required xsd:extension
xsd:complexContent xsd:complexType
The GML Application schema that defines the features and elements served by a WFS must require the use of feature and element identifiers that make WFS database
operations possible.
7.1.1 Globally unique identifiers Informative
For the purposes of a web feature service, a locally unique identifier is sufficient. However, there is a need within OGC web services to have unique identifiers for objects
of all kinds. The approach thus far has been to reference objects using independent scope and feature-id components, where the scope is the URL of the server serving a feature
and the feature-id is the local identifier for the feature. This approach, however, may be awkward to transport and use in other contexts, such as in a registry if one wanted to
create metadata for a single repository data instance such as a satellite image.
The purpose of this section of the specification is to point out that a single globally unique string would be more convenient to use in multiple contexts, and that such a string
may be generated by a web feature service using some combination of the URL of the service and the local identifier.
