Print This Post

GML and RESTful Architectures

It may come as a surprise, in some quarters, that GML works rather well in a RESTful world; some might even be surprised to see such remarks coming from me. There is no reason for surprise on either count. While I do believe that formally defined interfaces are both a useful approach to web services and, with suitable tools, can be easy to build and support, the origin of GML had nothing at all to do with the interface view of the world, and GML pre-dates its “companion” Web Feature Service (WFS) specification.

In the RESTful architectural style, interfaces are not the objective. Rather, the idea is to focus on the identification of resources and the provision of resource representations or encodings. GML began life, somewhat in contradistinction to the interface view, enshrined in CORBA (Common Object Request Broker Architecture). In a talk given in 1999 on xGML (my pre-cursor to GML), I felt compelled to defend a data encoding (read “resource representation”) point of view, with a slide entitled “Why encoding” and another entitled “Interfaces vs Encoding”.

GML was conceived as a means of representing resources that model objects in the physical world – what, in GML, are called Features. Every GML feature must have an Identifier. The original notion of identifier was much like that of RDF, from which may ideas in GML are borrowed, namely that the id was a local identifier of the object or feature that became global by virtue of its location path (thus composing an HTTP URI for the feature resource).

GML thought a lot about linking geographic entities to one another. Originally, the idea was that any property in GML (remember that GML properties conflate attributes and relationships) could be supplied with an xlink:href, the value of which “identified” the resource which was the value of the property. Early GML talks (circa 2001) talked about linking resource based on geographic scale (refinement), generalization, and the sharing of geometry. Almost every talk had a slide like the following:

What is GML?

The introduction of the WFS (and other OGC services) began to steer the ship in the direction of a greater focus on interfaces, and on the management of GML in relational databases (which did not support the xlink:href construct). This got many people thinking that somehow there was a conflict between GML and REST, but I think we can see that this could not be further from the truth.

Using the http implementation of the RESTful architectural style, we can see that GML fits rather nicely into a world of GET, PUT, and POST. If I create a geographic object and wish to assign it a particular resource identifier on the web (URI), I can easily do this with an http PUT method something like:

       <abc:Lake gml:id = “pl02”>
                     <gml:Polygon srsName =>
                                  <gml:LinearRing> … </gml:LinearRing>
              <abc:locatedIn xlink:href =

Someone else can request this feature using a simple GET operation, as in:


Since GML provides a formal description of all such geograohic resources through an application schema, which is also a resource, we can get the structure for the GML representation of an abc:Lake (or other feature types), just by requesting the schema with another GET operation, such as:


How to process the GML returned in these GET operations is quite straightforward. If a schema is returned, parse it for use in later query construction or use it to validate returned GML content. If XML (GML) is returned, parse it and possibly style it for presentation (e.g. to SVG or KML) or inspect the URI’s it contains (e.g. locatedIn property in the example above) and decide if these need to be requested, and so on. This process can be repeated many times, depending on the application processing semantics.

So GML fits just fine into a RESTful world!