[wms-dev] Suggestion for Common GetFeatureInfo Response Format
Keith Pomakis
pomakis at cubewerx.com
Mon Jan 23 10:45:47 EST 2006
Daniel Morissette wrote:
>> From WMS 1.3.1, section 7.4.3.6:
>
> Doh! Of course, I meant WMS 1.3.0 ... I haven't started working on WMS
> 1.3.1 in my spare time! :)
Actually, there is a WMS 1.3.1, sort of. It's not an official
specification like 1.3.0 is, but an unofficial one like WMS 1.0.1 through
WMS 1.0.8 were. I encourage everyone who is developing a WMS to support
this version, because it is more closely aligned with the OWS Common
Implementation Specification (OGC 04-016r5) and makes things like version
negotiation much easier and more efficient, while being only marginally
different from WMS 1.3.0. The remainder of this message is copied from
my wms.rwg message from 2005-04-18 on the subject of WMS 1.3.1.
----------------------------------------------------------------------------
Date: Mon, 18 Apr 2005 14:33:44 -0400
From: Keith Pomakis <pomakis at cubewerx.com>
To: wms.rwg at opengis.org
Subject: [Wms.rwg] WMS 1.3.1 proposal
In the interest of propelling the WMS Specification forward, I would
like to propose what I'm hoping will be accepted as WMS 1.3.1 within
the OGC community. Rather than attempting to completely align the WMS
specification with the OWS Common Implementation Specification (OGC
04-016r5) in one mega-step, I think that one or two intermediate steps
like this will aid in the transition process. I do not expect this to
become an "official" version at the same level of acceptance as WMS 1.3.0.
Rather, the intent is for it to be an intermediate version like WMS 1.0.1
through WMS 1.0.8 were.
This document may be considered the WMS 1.3.1 specification. However, it
is not a complete specification. It merely specifies the ways in which WMS
1.3.1 differs from WMS 1.3.0 (OGC 03-109r1). There are three differences:
1. Adopt the new AcceptVersions version-negotiation mechanism.
2. Adopt the new AcceptFormats format-negotiation mechanism.
3. Replace operation-specific elements with generic <Operation> element.
Each of these three differences are described in detail below.
The schemas for WMS 1.3.1 can be found at
http://schemas.cubewerx.com/schemas/wms/1.3.1/
The only change apart from the version number is in the way that the
<Operation> element is defined.
Comments please!
----------------------------------------------------------------------------
1. Adopt the new AcceptVersions version-negotiation mechanism.
Section 7.3.2 of the OWS Common Implementation Specification specifies a
version-negotiation mechanism that is superior to that of the existing
WMS specifications. The version-negotiation mechanism in the existing
WMS specifications is cumbersome, complex to implement correctly, and
often requires more than one request-response cycle. The new mechanism,
in contrast, is much simpler and allows a version to be negotiated in
exactly one request-response cycle.
Here is how Section 7.3.2 of the OWS Common Implementation Specification
defines this parameter:
Version negotiation is performed using the optional AcceptVersions
parameter in the GetCapabilities operation request. Although optional,
client software should always include this parameter, to simplify
version negotiation. The value of this parameter is a sequence of
protocol version numbers that the client supports, in order of client
preference.
The server, upon receiving a GetCapabilities request, shall
scan through this list and find the first version number that it
supports. It shall then return a service metadata document conforming
to that version of the specification, and containing that value of the
version parameter. If the list does not contain any version numbers
that the server supports, the server shall return an Exception with
exceptionCode="VersionNegotiationFailed".
To ensure backward compatibility, clients shall also be prepared to
accept an unknown response and treat this situation as an indication
that version negotiation has failed. Furthermore, if a server receives
a GetCapabilities request without the AcceptVersions parameter,
it shall return a service metadata document that is compliant to
the highest protocol version that the server supports. This makes it
convenient for humans to make requests manually, and allows for forward
compatibility with possible future incarnations of version negotiation.
This new version negotiation process is designed to be compatible with
the old-style version negotiation that was defined in earlier versions
of the various OWS specifications, as described in Subclause C.11.
Here is the relevant part of the abovementioned Subclause C.11:
C.11 Version negotiation backward compatibility
The new version negotiation process, defined in Subclause 7.3.2,
was designed to be compatible with the old-style version negotiation
defined in earlier versions of the various OWS specifications. That
old-style version negotiation used the optional version parameter in
a GetCapabilities request.
The old-style version negotiation process stated that if the version
parameter is missing, then a service metadata document compliant to
the highest-supported version shall be returned. Therefore, if a new
client sends a GetCapabilities request containing an AcceptVersions
parameter to an old server that does not recognize it, the server will
return a service metadata document compliant to the highest version
that it supports. The client will either recognize this version, in
which case version negotiation has been successful, or it does not. In
the situation where the client sees a service metadata document for
a version that it does not support, the client may optionally revert
back to the old-style version negotiation mechanism to complete
the negotiation.
A server may also optionally implement the old-style version
negotiation mechanism so that old clients that send GetCapabilities
requests containing a version parameter can be served. If both a
version and an AcceptVersions parameter exist in a GetCapabilities
request, the server shall ignore the version parameter.
----------------------------------------------------------------------------
2. Adopt the new AcceptFormats format-negotiation mechanism.
Section 7.3.5 of the OWS Common Implementation Specification specifies a
format-negotiation mechanism that allows a client to attempt to negotiate a
GetCapabilities operation response format other than "text/xml". Here is
how this parameter is defined:
The optional AcceptFormats parameter can be used by a client to attempt
to negotiate a GetCapabilities operation response format other than
"text/xml". When included in an operation request, this parameter
shall contain a list of the alternative MIME types that the client
wants to be returned, listed in the client's preferred order. The
MIME type "text/xml" is always an implicit last option, but can be
explicitly included.
When a server implements the AcceptFormats parameter and receives a
value for it, the server shall return the Capabilities document in
the format of the first MIME type in this list that it is capable
of returning. When not received or not implemented, the server shall
return the Capabilities document in normal XML, using the MIME type
"text/xml". All clients and servers shall implement the "text/xml"
MIME type for the GetCapabilities operation. Since "text/xml" is
always an implicit last option, the server always has an implemented
MIME type to use to return a Capabilities document to the client.
Server and client implementation of this parameter is optional. A
variety of alternative formats (with different MIME types) have been
proposed for transfer of XML documents, but many have not yet been
completely specified, and none has yet been widely accepted. Many of
these alternative formats reduce the size of the transferred message,
thus reducing the communication time and load.
This document does not now specify any alternative format, but
the AcceptFormats parameter is included to provide flexibility to
allow experimentation and allow other documents to identify allowed
alternative format(s). A specific OWS Implementation Specification
that expects to interoperably use this AcceptFormats parameter shall
thus identify the alternative format(s) that can be used (or that
shall be implemented by servers).
EXAMPLE 1 One possible alternative format is the ISO standard for
binary encoding of MPEG-7 or BiM as specified in [ISO/IEC 15938-1],
with MIME type "application/x-bix".
EXAMPLE 2 Another possible alternative format is BXML as specified in
[OGC 03-002r8], with MIME type "application/x-bxml".
NOTE A non-XML format whose MIME type is well-defined might be used
if a method is specified to convert a Capabilities XML document,
as specified herein, into that alternative format.
----------------------------------------------------------------------------
3. Replace operation-specific elements with generic <Operation> element.
The WMS 1.3.0 specification makes it cumbersome for a WMS server to add
vendor-specific operations. To do so, it must define its own schema and
create subtypes of the abstract _ExtendedOperation type. The OWS Common
Implementation Specification proposes a more elegant solution. Rather than
having a specific element for each of the known operation types and a
separate extension mechanism for adding vendor-specific operation types,
a simple <Operation> element with a "name" attribute shall be used.
E.g., rather than:
<GetMap>
<Format>image/png</Format>
<Format>image/gif</Format>
<DCPType>
<HTTP>
<Get>
<OnlineResource type="simple"
href="http://demo.cubewerx.com/demo/cubeserv/cubeserv.cgi&"/>
</Get>
</HTTP>
</DCPType>
</GetMap>
the following shall be reported:
<Operation name="GetMap">
<Format>image/png</Format>
<Format>image/gif</Format>
<DCPType>
<HTTP>
<Get>
<OnlineResource type="simple"
href="http://demo.cubewerx.com/demo/cubeserv/cubeserv.cgi&"/>
</Get>
</HTTP>
</DCPType>
</Operation>
The OWS Common Implementation Specification makes more drastic changes to
the <Operation> element, but WMS 1.3.1 does not adopt these other changes.
----------------------------------------------------------------------------
Date: Fri, 29 Apr 2005 11:47:28 -0400
From: Keith Pomakis <pomakis at cubewerx.com>
To: wms.rwg at opengis.org
Subject: Re: [Wms.rwg] Re: WMS 1.3.1 proposal
Jeff de La Beaujardiere <jeff2005 at svs.gsfc.nasa.gov> wrote:
> Regarding WMS 1.3.1 specifically: I think a small schema change like
> changing the multiplicity of EX_GeographicBoundingBox from 1 to 1+ is
> legitimate. Defining a new BBOX envelope element, or switching to use of
> GML geometry, is a larger change more suited for a 1.4-level revision.
Agreed. So if there are no objections, I'll make this simple change to
the WMS 1.3.1 schema. Specifically, I'll change:
<element ref="wms:EX_GeographicBoundingBox" minOccurs="0"/>
to:
<element ref="wms:EX_GeographicBoundingBox" minOccurs="0"
maxOccurs="unbounded"/>
Simple clients that are only able to deal with one bounding box can
calculate a single bounding box from the union of the reported bounding
boxes.
.--------------------------------------------+------------------------------.
| Keith Pomakis | E-mail: pomakis at cubewerx.com |
| Senior Software Developer, CubeWerx Inc. | Phone: (819) 771-8303 x204 |
| 200 rue Montcalm, Gatineau, Québec J8Y 3B5 | Fax: (819) 771-8388 |
+--------------------------------------------+------------------------------+
| WWW home page: "http://www.pobox.com/~pomakis/" |
`---------------------------------------------------------------------------'
More information about the wms-dev
mailing list