NOTE: The wcsplus mailing list is no longer active. The list archives are made available for historical reasons.
Dear Jon,Thank you for the interesting comments. Actually our paper was conceived to raise and discuss similar points. In fact, these subjects are quite open and under investigation.
Let me start answering to your last point; the answers to your other comments will follow in another email.
4) "While OWS POX binding is not a RESTful implementation it is still implicitly resource-oriented since it is based on a uniform interface (getSomething) on different resources (capabilities, descriptions, coverages, features, etc.)." I see what you are saying here, but I still see OWS as being query-oriented (the query is the important part of the protocol, not the data payload). Queries are not CRUD operations in the usual sense. Yes, OWS is based on access to resources but in fact there are an *infinite* number of possible resources (coverage subsets, feature subsets, etc). As I said in a previous email the REST approach might improve the URI syntax for OWS requests but I'm still not convinced of its value otherwise: I still worry that it makes little sense - and provides little real value - to try to converge the REST and OWS worlds.
Frankly speaking, I didn't want to state that the REST approach is the "best" way to implement OWS. We started considering some REST successful stories and we wanted to understand the benefits and limitations for Geo-information Web-based infrastructures. In order to explore this possibility there exists the need to define a complete and realistic REST framework for geo-information. This was the main motivation for our document.
Said that, I would like to answer to your important point: the query nature of OWS and the infinite number of resources.
A valuable case of REST approach is the SQL. In fact the SQL commands implement the CRUD functionalities, the FROM-WHERE clauses expresses unique resource IDs. SQL proved to be a very successful technology. It was conceived to implement access to information stored in DB. Actually SQL stands for Structured Query Language, thus, the query aspect was central in the SQL definition. You may use the SQL clauses to select *infinite* number of possible resources (i.e. set of tuples from one or more joined tables/views). SQL commands and keywords are relative few; command semantic is "simple". In other words, they define a quite fix and "general" interface protocol.
Our point is whether it is possible to use the REST Web technologies for Geodata infrastructures as SQL technology has been used for DB infrastructures.
Regards, --Stefano
wcsplus archives: