02 Oct 2008 - KML, GML and REST

In the past several months there has been a great deal of discussion of the merits of REST-based architectures within the OGC and the wider IT community, with adherents on both sides claiming superiority for their respective viewpoint, and with only a small amount of understanding transiting from one community to the other.

I thought in this context it would be interesting to look at the history of GML, KML in relation to REST.

The origins of GML belong with the early days of the “new web”, meaning the suite of specifications including XML, XLink, XPointer, XSLT, RDF that sought to extend what one might think of as the conventional web, by abstracting the web’s basic notions like resources (from web pages, web sites), resource identifiers, and linking (href).  In this generalization of the web of documents, generalized resources (often in XML) would replace web pages (XHTML), and XLinks would link or associate these resources much as href and anchor tags connected web pages.  While things were never totally clear, the essential idea was that this web of linked resources would be independent of its presentation which would be based on HTML or some other FO (Format Objects) generated courtesy of XSLT.  The value of XLink:href attributes would then be XPointer expressions that easily picked the resource of resource component of interest across the web.  When this model was applied to web pages it appeared to offer significant improvements over HTML including finer grained references, multi-direction references, and the ability to link to resources in a page, not just to positions in the page.

GML was built on these basic ideas for geographic information.  Geographic entities would be XML resources (with identity) which could be linked together across the web (via href:xlink) with GML providing the building blocks (e.g. geometry) and the model for constructing these resources.  Large networks of these resources were envisioned so that one might navigate from a geographic dataset for a nation to that of local land parcel in a few mouse clicks.

With the emphasis on GML resources, its RDF heritage, and the use of XLinks one might think that GML and REST were made for each other.  Trouble was, however, brewing on the other side of the fence, namely databases and especially spatial databases.  This was not a world of unique identifiers and even less of linked resources, most especially if those resources spanned multiple databases.  Databases, especially relational databases had a different take on the world, one focused on queries and operations, and one in which resources were results or things to be operated on, and not something intrinsic to the model.

The result of this database influence surfaced in the OGC Web Feature Service (WFS), essentially an XML encoding of SQL with spatial extensions.  It used GML applications schemas (response to DescribeFeatureType) and GML as a data transport (response to GML GetFeature requests).  The idea of resource identifiers and resource linking was a problem, and both aspects did not appear in version 1.0 of the WFS, and were only weakly supported if at all in WFS 1.1, which is still the most current version that has been released.

The WFS is clearly focused on operations and queries, and is in this sense, not very RESTful.

The WFS is not unlike many other web services, especially those identified with SOAP, where the viewpoint of operations dominates the discussion.  HTTP GET and POST appear of course, but only as data transports, with the semantics of the request really encoded in the WFS (or other web service) operations.

What about KML?  KML borrowed a great deal from GML, including the encoding of geometry primitives and the use of remote referencing (href), while leaving the more general GML feature model to one side.  KML began as file centric (literally OS files) so that the structure of the XML (KML) was always visible and accessible to the user.  KML links to other KML files (or other resources) just as in GML represented through hrefs, but without the requirement that these be xlink:href’s – i.e. no need to be XPointer expressions, although XPointer could do very interesting things with KML.   Google and other imagine deep networks of KML files are all linked together.

With advances in database support for XML  (e.g. XML abstract types, XML databases, XQuery, XML binding frameworks) the vision of linked XML resources that reside in databases and which are retrievable by queries and on which transactions can operate need not be in conflict.  REST and the world of SOAP/SOA can co-exist.

Comments

No comments yet.