[Requests] Harmonize the request parameters of the ESRI proposed map request handling service (12-056)

Adrian Custer ac at pocz.org
Mon Jul 23 13:06:45 EDT 2012


Change Request


PART A


1. Evaluator:
         Adrian Custer
	ac at pocz.org

2. Submission:
	GeoServices REST API - Part 3: Map Service (12-056r1)


PART B


1. Requirement:
	General - All the parameters of the Map Service


2. Implementation Specification Section number:
	General - Sections 7 through 23


3. Criticality:
	Major


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 
coming decades.

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
	implementations.
One wonders why the OGC should wait until *after* initial publication to 
begin the standardization and harmonization work.


	Adrian Custer


More information about the Requests mailing list