[Requests] Rewrite the proposed ESRI web service specifications (12-054 .. 12-062) as profiles of existing OGC services

Adrian Custer ac at pocz.org
Mon Jul 23 12:29:50 EDT 2012


Change Request


PART A


1. Evaluator:
	Adrian Custer
	ac at pocz.org

2. Submission:
	GeoServices REST API - Part 1: Core (12-054r1)
	...
	GeoServices REST API - Part 3: Map Service (12-056r1)
	...
	GeoServices ... - relationship with the OGC baseline (12-062r1)

	(12-054 through 12-062)


PART B


1. Requirement:
	All requirements, plus the rest of the documents themselves


2. Implementation Specification Section number:
	All sections


3. Criticality:
	Blocker


4. Comments/justifications for changes:

The documents proposed by ESRI for adoption at the OGC under the 
collective title "GeoServices REST API" should become well written 
profiles of the existing OGC Web Services.

The documents propose web services whose functionality largely overlaps 
that of existing services (and confusingly the documents reuse the names 
of the existing services) but whose functionality is uniquely 
constrained to a simple model of geospatial features. Since this is 
*exactly* the kind of usage for which the current services are being 
rewritten and modularized, the documents should become profiles of the 
current services, defining services backed by simplified, tabular 
feature stores. The amount of work would actually be less than the 
amount of work required to clean up the current documents so they 
correctly specify what they are trying to specify. In the mean time, 
since ESRI retains copyright to its submission, if it feels the 
specifications are adequate, ESRI could publish them as their own 
specification document for the existing ESRI service.




The overlap with existing web services is a key source of 
interoperability issues. The documents do not even provide way for OGC 
members to distinguish issues related to the one service kind versus the 
other: when we say "the map service parameter" how are we to distinguish 
which map service we are discussing? We currently have the "OGC Map 
Service" but what is this new one, the 'GeoService Map Service', the 
'REST Map Service', or the 'ESRI Map Service'? Only the latter one makes 
semantic sense since the existing OGC Map Service is clearly a Geo* 
Service (as are all OGC Web Services) and will soon have RESTful 
profiles. The proposed web services are different in that they provide a 
simple communication style to services backed by feature stores with a 
simple, flat feature attribute model. That should be front and center so 
that we could talk of the 'Tabular Feature Map Service' but really it is 
the "Map request interface to the Multipurpose Tabular Feature Service". 
The proposed documents must distinguish the nature of the proposed 
services from the existing services to prevent tiresome confusion in the 
next few years.




The documents need an enormous amount of work to become useful 
specifications for the proposed services, work that could be better 
spent in a harmonization effort.

The work required to turn the proposals into useful specifications is 
outlined in a series of Change Requests of which this is the first. In 
brief, the requirements need a global review because they are generally 
badly phrased and often propose untestable injunctions, the conformance 
tests need to actually be written since the proposed tests are stopgag 
placeholders that state 'test this stuff to make sure it is so' rather 
than specific tests which clarify the requirements, and the 
functionality of the services needs actually to be specified since the 
current documents will do things like introduce a request element but 
never even explain what it is supposed to change, let alone develop 
rigorous injunctions and targeted tests for the impact of that parameter.

The proposed documents essentially need to traverse the past decade of 
work of the current standards. Whereas existing web service standards 
are being rewritten to clarify all sorts of detailed aspects of their 
behavior and exchanged resources, the proposed documents offer none of 
this clarity. Similarly, the proposed documents do not even follow 
standard industry practices in things as simple as how they specify file 
formats. They are repeating errors made a decade ago in the existing OGC 
services.




The OGC membership should encourage the authors to develop the proposed 
functionality as a series of well written Profiles of existing services, 
profiles which define multipurpose geospatial services backed by a 
simplified, tabular feature model.


     Adrian Custer



More information about the Requests mailing list