[Requests] WMTS Candidate

Sean Gillies sean.gillies at gmail.com
Wed Mar 18 14:47:26 EDT 2009


PART A


1. Evaluator:
         Sean Gillies
         sean.gillies at gmail.com


2. Submission: OGC 07-057r6



PART B


1. Requirement: [General, #]


2. Implementation Specification Section number: 10


3. Criticality: Major


4. Comments/justifications for changes:

See also http://groups.google.com/group/geo-web-rest/browse_frm/thread/fa0633b1dd009c02#

The "RESTful encoding" in the proposed WMTS specification is harmful  
to the geospatial community's understanding of REST.

http://www.opengeospatial.org/standards/requests/54

Among other things, a RESTful tile service must give clients a  
bookmarkable entry point from which it can find tile resources. The  
"RESTful" WMTS does not. The service metadata document  only provides  
the base URL. Clients can not follow their noses from there. The  
proposed WMTS is not RESTful.

Furthermore, GetResourceRepresentation (especially sections 10.2.1 and  
10.3.2) isn't a RESTful protocol as much as it is hierarchical URL  
fetishism. Let's accept (for now) the essential parameters as they are:

  WMTSBaseURL
  layer
  style
  firstDimension
  lastDimension
  TileMatrixSet
  TileMatrix
  TileRow
  TileCol

Requiring all tiles to be at URLs like

1) {WMTSBaseURL}/{layer}/{style}/{firstDimension}/{...}/ 
{lastDimension}/{TileMatrix
Set}/{TileMatrix}/{TileRow}/{TileCol},

in that exact order, has no demonstrable benefit unless the resource  
at (for example)

{WMTSBaseURL}/{layer}

always contains links to the contained styles. Strict hypertext as  
engine of application state, in other words. Since there's no sign of  
the hypertext constraint in the spec, I see no reason why a URL like

2) {WMTSBaseURL}? 
l 
= 
{layer}&s={style}&fd={firstDimension}&ld={lastDimension}&tms={TileMatrix
Set}&tm={TileMatrix}&tr={TileRow}&tc={TileCol},

or any other ordering of the parameters in a query string, shouldn't  
be equally valid.

This proposed WMTS spec cries out for URI templating, the kind of  
hypertext used in the OpenSocial API [1]. The one bookmarkable entry  
point for the service would be an XML document that provides URI  
templates to a client, using forms 1 or 2 (shown above). This way, you  
can avoid baking a particular server implementation into clients  
unnecessarily [2].

There are good elements in it, but the proposed specification should  
be withdrawn and reworked, making it into a specification that  
enlightens users about REST.

[1] http://docs.google.com/Doc?id=dc43mmng_2g6k9qzfb&hl=en
[2] http://www.abstractioneer.org/2008/05/xrds-simple-yadis-uri-templates.html

--
Sean Gillies
Software Engineer
Institute for the Study of the Ancient World
New York University


More information about the Requests mailing list