[Requests] Harmonize the request parameters of the ESRI proposed map request handling service (12-056)
ac at pocz.org
Mon Jul 23 13:06:45 EDT 2012
ac at pocz.org
GeoServices REST API - Part 3: Map Service (12-056r1)
General - All the parameters of the Map Service
2. Implementation Specification Section number:
General - Sections 7 through 23
4. Comments/justifications for changes: [Comments]
The proposed standard includes parameters which are inexpressive,
confusing, or otherwise problematic, hindering interoperability.
For interoperability across users, implementers, linguistic groups, and
communities of interest, communication elements should express
effectively their meaning. Communication elements should also reuse the
language from the major, existing standards where possible, and only
introduce new elements where strictly necessary, something which has
been OGC practice up to now. Communication elements should be distinct
from elements which already exist when expressing a different concept so
as to prevent confusion. The proposed service violates these notions.
For example, the proposed Map Service suggests the use of the parameter
'f' for communication. That parameter has strictly no meaning to anyone
on its own, which is unfortunate because the concept could be relatively
straight forwards and exists in most existing web services. The concept
has an existing expression in the HTTP message grammar itself, as one of
the message headers. (The proposed specification document fails to
address conflicts in those two modes of communicating the same idea.)
The concept also has existing expression in current OGC web services.
Since the parameter 'f' communicates nothing in of itself and because
more expressive alternatives exist, the use of 'f' is silly. Much worse,
the use of bespoke values for this parameter, rather than the flexible,
extensible, industry standard, MIME type notation, is downright foolish.
For another example, the proposed Map Service suggests the use of the
parameter 'format' for communication to indicate the format of the image
returned. However, in existing OGC Web Services, that parameter means
the format of the response (which the proposal calls 'f') and can be
used for other types of request like the request for the capabilities
document. Since the proposed document's usage conflicts with all
existing OGC Services, this causes an interoperability issue which will
last as long as the services need to co-exist.
These two examples just begin the process of formal analysis of the
proposal. The issues could be resolved by changing the parameter names
or even by prefixing them all with a token specific to the services, say
"EWS_format" for the 'format' parameter used by the 'ESRI Web Services.'
However, I will not take the time to develop this analysis further since
it is clear that the authoring SWG members have no interest in improving
their proposal beyond the currently defined ESRI implementation. If the
authoring SWG wishes help in the future, the Web Map Service SWG has
many members who would welcome an open, collaborative exchange on how to
build the best standards for users, the industry, and our needs in the
One of the proposed documents (12-062) states:
... the GeoServices REST API services should be seen as
complementary to the existing OGC Web Services. Over time,
harmonization between the specifications should be considered
with regards to the necessary migration for existing
One wonders why the OGC should wait until *after* initial publication to
begin the standardization and harmonization work.
More information about the Requests