Lost in Abstraction – What Went Wrong with GML

Joel Spolsky wrote a classic post back in 2001 titled Don’t Let Architecture Astronauts Scare You, which warns that the more abstract a solution to a problem is the less useful it becomes. Abstraction is a funny thing – just the right amount gives you the insight to solve previously unsolvable problems but too much obscures what you are trying to accomplish thereby leading you astray.

Atom is great example of an standard that gets the abstraction level right – as I wrote the other day its simple model of collections containing entries turns out be a very useful way to view the world.

In contrast, the Geography Markup Language (GML), which is the GIS industry’s primary data exchange format, is a standard that gets it wrong. Even if you know nothing about GIS or GML its a good example of trying so solve a problem by adding one too many levels of abstraction thereby solving nothing.

What’s Your View of the World?

GML sets out to solve an awfully difficult problem – how can different systems exchange geographic information (if you want to be hip, go with spatial information instead)?

The funny thing is the geometry part is fairly easy – put a few smart people in a room and they can come up with some reasonable way of describing points, lines, polygons and how they may or may not connect (you’d say roads connect with one another, but probably not to your front yard).

No, the hard bit is trying to describe the world. When you work with geographic information you immediately come face-to-face with the realization you’re trying to model the real world. Of course that’s true for any computer system, such as your company’s payroll system, but somehow dealing with the physicality of the world really drives the point home.

Thus the real problem GML tries to solve is how can your computer system and my computer system exchange data about the world in a meaningful way? In my opinion that’s an unsolvable problem, because the way your database models the world is different than mine. There is a fantastic book on the subject, called Data and Reality, that every programmer, architect and model should read. I wrote about it last year, and to quote the post:

Take a simple term – say a street. What it is it? Have you ever been on a street that ends, and then starts up in a few blocks? Is that the same street? How about a street whose name changes – is it still the same street? Does a street include boulevards, highways, freeways? Does a street cross city, county, state boundaries? Do you and I live on the same street, although I live in the United States and you live in Canada?

A Good Start – Take #1

GML 1 took a fairly simplistic way of solving the problem. You could define collections of features, with each feature having “normal” properties and geometric properties. For example, a road might look like this:

<Feature typeName="Road">
  <description>M11</description>
  <property typeName="classification">motorway</property>
  <property typeName="number" type="integer">11</property>
  <geometricProperty typeName="linearGeometry">
    <LineString srsName="EPSG:4326">
      <coordinates>
        0.0,100.0 100.0,0.0
      </coordinates>
    </LineString>
  </geometricProperty>
</Feature>

Having implemented the first commercial support of GML (in the Smallworld Internet Application Server), I can say that GML 1 was easy to implement and gave us a good way to exchange data between clients and servers.

A Standard Goes Awry – Take #2

And then things fell apart. GML 2 abandoned its RDF like flavor and replaced it with…well…nothing. Instead, GML moved up a level of abstraction.

Say what? Instead of saying “this is how you encode a road” it now says “this is how you construct a model that will let you encode a road.” Thus GML turned itself into a modeling language. If you’re a programmer, a good analogy is UML, the universal modeling language. UML provides you the tools for modeling computer programs, which you then implement in some programming language. GML provides you the tools to model the world in the way you see fit, and then implement it via XML. To do this, GML uses XML Schema as its modeling language and makes use of every last obscure feature, including such gems as substitution groups.

What is a Client to Do?

So how does this work in the real world? Let’s say I want to model the road I showed above. First I have to create an XML Schema that defines a Road Feature, which must inherit from the appropriate abstract GML classes. Then I write out the road in an XML document that validates against the schema I just wrote.

But think of the poor client – what is it supposed to do with the xml document it just received from my server? Well – there are three obvious approaches.

First choice – hard-code the client to know exactly how I described a road.

Second choice – build a hugely complex piece of software that can read in the XML schema, generate an implementation of it on the fly, then load in the XML data. This is in fact possible – and exactly what I did when implementing our GML 2.0 support. However, after all that work, you still need a human to map the incoming data to your data model. In theory, being able to declare the mapping in a configuration file should be more flexible/powerful than coding the transformation by hand (like in the first choice). And maybe that’s true in some programming languages. But if you’re using a dynamic language like Ruby or Python, then the advantage is much less clear-cut. Having taken this approach once, I would not do it again.

Third choice – Every one agrees on a standard way of exchanging information and everyone then hard-codes their system to use it. This in fact is the solution that GML is headed towards by creating “GML Profiles.” As the GML Simple Profile Feature states:

The GML specification declares a large number of XML elements and attributes meant to
support a wide variety of capabilities…With such a wide scope, interoperability can only be achieved by defining
profiles of GML that deal with a restricted subset of GML capabilities.

At this point you might be asking why exactly you went through the whole effort of creating a custom xml schema or even using GML. Good question – I don’t have a good answer.

And This Solves What?

After seven years, the GML spec now weighs in at 548 pages with a 24 page index. Its numbing complexity has resulted in the development of several GML profiles, with the “Simple” one coming in at over 100 more pages.

In my view, the fundamental premise of GML is wrong. The ability to create custom data models is an anti-feature that makes integration between different computer systems impossible because it assumes that those systems can actually understand the data. Computer systems have no such intelligence – they only understand what someone has programmed them to understand.

To hit the sweet spot you must come up with a standard, simple format that every system can use. As Tim Bray, the father of XML, states:

The value of a markup language is proportional approximately to the square of the number of different software implementations that can process it. I could argue this from theory but would prefer to do so by example: HTML. RSS. PDF.

If you insist upon adding extensions, then at least come up with a standard base format like Atom has. GML offers no such simple standard, and as a result its adoption in the world is much less that it could have been, or should have been.

Instead mindshare has now switched to KML, a simpler and easier to understand format. KML is hardly perfect – you can’t define your own properties (as far as I can see) and it commits the cardinal sin of mixing presentation and data (didn’t we finally get past that with HTML and CSS?). But this game is over, KML has won.

  1. May 1, 2007

    Nice post. I wouldn’t say that mindshare has switched to KML, just that GML was never even considered for what OGC would refer to as “mass market” use (because of the reasons you provide).

    I’ve always been a bit scared of GML because of the modelling stuff and a lack of simple examples, and have got by with the other “good enough” interchange methods out there.

    Couple notes on KML:

    – there is the Schema element that allows you to override the Placemark with your own properties. They seem to be backing away from this in favour of the Metadata tag which, because it requires external schemas, I find annoying.

    – while is is possible to store style information in a placemark, KML provides facilities to reference a style defined once per document, or even in an entirely seperate document. This is analogous to the way that CSS can be used in HTML.

    Jason

    Reply
  2. Charlie
    May 2, 2007

    Glad you liked the post Jason.

    In my view the OpenGIS Consortium definitely intended GML to become “the way” of exchanging spatial data. GML has had some success, such as in the federal government market. But I don’t think it has succeeded out on the web.

    Thanks for the pointers on KML – using an external stylesheet definitely seems the way to go. And I’ll check out the meta tag.

    Reply
  3. May 3, 2007

    Bryan said it when he said: toolkit. Customers don’t like toolkits. Programmers design those for themselves. They like products that do the job at hand.

    In the HyTime days when we were designing the MID language for the US Navy, MID I was (in 1994) what XAML and now Silverlight are now. At every successive meeting, ambitions to make the language do everything increased the abstraction until at last, it became ISMID, a sort of toolkit.

    Of course it died. All toolkits rely on excessively complext object-frameworks for deriving the objects to derive the objects, and that always fails because it takes too long to do anything useful. I tell designers using application languages such as X3D, never show a customer something where when they see it they ask, “And what could I do with that?” What you want to hear is, “I can use that for THIS!” Then they buy.

    When doing the MID, David Cooper at Antech had an idea for a t-shirt to describe the analysis paralysis that happens once a good idea goes back into committee. It read “More Meta Than Thou.” It is a disease of the ego.

    Reply
  4. Steve Bell
    May 11, 2007

    Hi Charlie. Having just had the job of overseeing implementation of GML 2 in the latest version of SIAS, I can heartily agree with the abstraction point. I have one word to say to you, though: MetaMagik 😉

    Reply
  5. Charlie Savage –
    May 11, 2007

    Hey Steve – did you actually use MetaMagik? If so I’m impressed. I should blog about it, although I’m guessing it will bore most people to tears 🙁

    I just assumed all that stuff got lost in the transition to Cambridge….Anyway, would love to hear more about what you’ve done and your experiences.

    Reply
  6. Steve Bell
    May 15, 2007

    MetaMagik actually lived on a while after you left – Shashi took it over (and seemed to actually understand it!) but then she left as well and I didn’t find an excuse quickly enough. I kinda got my head round the XMI thing – interesting in concept, but essentially way too flexible for what it was to be used for. A perfect example of what you’re talking about in the blog. BTW I feel more comfortable saying this after seeing your comment on XMI and kool-aid (although I had to wiki what the kool-aid thing meant 🙂 Anyway, MetaMagik finally got thrown out after the SIAS4 development came to Cambridge; the decision was made not to persist with SIAS4 as it stood, but to re-release 2.1 with some fixes as 4 and then re-architect on J2EE. That’s the effort that I led last year, and we released in January.

    Reply

Leave a Reply

Your email address will not be published.

Top