Date: Mon, 18 Apr 2005 14:33:44 -0400 From: Keith Pomakis To: wms.rwg@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 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 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 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 element with a "name" attribute shall be used. E.g., rather than: image/png image/gif the following shall be reported: image/png image/gif The OWS Common Implementation Specification makes more drastic changes to the element, but WMS 1.3.1 does not adopt these other changes. .--------------------------------------------+------------------------------. | Keith Pomakis | E-mail: pomakis@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/" | `---------------------------------------------------------------------------'