[Requests] OpenGIS Web Processing Service (RFPC 28) Response

[Jeff Yutzler]

Part A is to be completed once per evaluator per comment submission. 
Please iterate over Part B as needed.

PART A
------
1. Evaluator: [CONTACT INFORMATION]

Jeff Yutzler
Ionic Enterprise, Inc.
jeff at ionicenterprise.com

2. Submission: OGC Request 28: Web Processing Service (WPS): Request for 
Public Comments


PART B
------
1. Specification Section number: [GENERAL, #]

GENERAL

2. Criticality: [MAJOR, MINOR, EDITORIAL, ETC.]

EDITORIAL

3. Comments/justifications for changes: [COMMENTS, SUGGESTIONS]

We have observed with interest the development of the Web Processing 
Service specification.  We hoped to see a new specification that would 
provide a tangible benefit to OGC users by providing a mechanism that 
would be an improvement over the existing mechanisms that can be used 
for executing arbitrary processes, such as SLD and OGC Filter.  After 
watching the process for a number of months, we are now convinced that 
OGC is headed in the wrong direction here.  Instead of a useful 
specification, what we see is a specification that competes with 
SOAP/WSDL without providing any real benefits to either the OGC 
community or the geospatial community at large.  For this reason, we 
oppose the initiative to adopt the Web Processing Service as an OGC 
Implementation Specification.

There are three things that would make a technology a suitable OGC 
Implementation Specification.
1. GeoSpatial component.  In reviewing the Implementation Specification, 
there is hardly any mention of geospatial components at all.  The only 
components specifically mentioned are input and output bounding box.  In 
reality, the descriptions are so generic that they could be used for 
anything at all.  There is nothing about the specification that makes it 
specifically suitable or beneficial to the geospatial community.  The 
existing SOAP/WSDL specifications are already widely used outside of OGC 
and are equally well suited to working with geospatial data.  This 
suggests that at best, this specification is outside of the scope of the 
OGC.

2. Interoperability.  A suitable definition for interoperability in this 
context is "Products and systems from multiple vendors that can be used 
together without modification or development of custom interfaces and 
tools."(1)  This suggests a service that can be developed and exploited 
with the Publish, Find, Bind model.  This "specification" does not meet 
this criteria at all.  Since there is no semantic component to the 
specification, it is impossible to exploit a new WPS without knowing its 
intimate details.
Take the example of a buffering service.  If an organization decides to 
develop a buffering service and publish it as a WPS, the clients must 
know the specific inputs and outputs and then develop custom software in 
order to exploit it properly.  Once a buffering service exists, no one 
else is likely to develop another one because it would be redundant.  
After all, if a buffering service works as advertised, there is no 
reason to develop a second one unless the second one has new 
capabilities not supported by the first one.  In the event that the 
first buffering service is insufficient, a new one could be developed, 
but it would have different inputs and/or outputs that would require 
additional custom software to be able to exploit.
The only "interoperability" this specification provides is a standard 
template for publishing arbitrary services.  It is not even possible for 
these services to be interoperable the way it is written.  This template 
comes nowhere close to the criteria expected of an OGC Implementation 
Specification.

3. New capability not supported by existing specifications.  A review of 
the successful TIEs reveals that most of the test cases involve 
repackaging of existing services as WPS.  There is nothing here that can 
not be done with existing web services or with SOAP/WSDL.  This is not 
progress.  There are a number of technological problems such as service 
chaining that have been ignored by the TIEs.  Since this "specification" 
does not give the community any abilities they did not have before, why 
bother?

OGC should be committed to developing specifications that provide new 
capabilities that are made possible by the interoperability of 
geospatial components.  Rather than developing a specification that can 
benefit many members of the OGC community, what we have here is a small 
subset of members who have developed this specification to benefit 
themselves, with the hope that being able to use the OGC banner will 
give it legitimacy and give them a competitive advantage.  This misuse 
of OGC resources should not be encouraged or supported.  It is a waste 
of resources for OGC to put forward this competing specification as a 
candidate for adoption.

(1) *Bridgefield Group ERP/Supply chain Glossary. Internet posting at 
http://www.bridgefieldgroup.com/glos4.htm
*
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jeff.vcf
Type: text/x-vcard
Size: 297 bytes
Desc: not available
Url : https://mail.opengeospatial.org/mailman/private/requests/attachments/20060130/b5bd19b4/jeff.vcf