Print This Post

If you have an XML face, should you have an XML heart?

A recent blog post by Don Murray, one of our friends at Safe Software, entitled Defeating XML & GML (Part 1/2: Conquer the Fear), noted the importance of XML for data exchange, and asked you to substitute GML, if that was to your liking, throughout their article.  At first, it might be surprising to hear that GML is now mainstream, and that people were overcoming their fear of it, but that is only from the perspective of an early adopter.  For the mature mass of users, XML and GML are still new things, and the availability of tools that are not only easy to use, but familiar, is critical to their acceptance of it.

Don makes a number of good points in his blog.  It is the data that matters, and the apparent complexity of GML (I will use GML since I am thinking about geospatial data) stems from the complexity of data models, and not from GML itself.  If you have a simple shape file (meaning a .shp file, a .prj file, and a .dbf file) and translate it to GML, you will have a much simpler, single, GML file that you can read like a comic book, even if you know little or nothing about XML or GML.  The complexity is in your data, and in the data models that you build.  Keep them simple!

If we compare aging standards such as Shape, or VMap, or S57, GML looks sparkling in its simplicity.  It is just that you don’t normally look at a Shape file or an S57 file; you look at a rendering of it through a tool interface.  As the tools by Safe and others improve, you will come to think in the same way about GML as you do about a shape file.  We will also see, and are starting to see already, content level models (e.g. GML Application Schemas like CityGML, DIGGS, and AIXM) that further simplify your universe, and to use these you will never need to look at angle brackets again.

The mainstreaming of XML makes me think back to an adage I promoted in the early days of GML – namely “if you have a GML (XML) face, should you also have an XML heart?”  What does that mean?

If GML (XML) is the lingua franca of data exchange, perhaps we should start managing, storing, and operating on it that way.  This does not mean that we need to store everything as text (although that is great for archival purposes), but it does mean that more GML-aware storage, processing, and management (“the GML heart”) would make a great deal of sense.  Why keep translating back and forth to a relational data store that is NOT GML (XML) friendly?  This is painful, even for objects, in spite of all of the work that has gone into J2EE.  Going from a GML (XML Schema) -aware data store to in-memory objects is much, much easier, since XML Schema is much closer to an object model than a relational model.

At Galdos, we have developed a Web Feature Service, INscape (http://www.galdosinc.com/technologies/products/inscape) that runs on the very powerful EMC Documentum XDB, which is a native XML database.  With this approach, we have none of the headaches of schema mapping that we encounter with relational stores (we also provide INscape on Oracle and ArcGIS Server), and we can be immediately up and running with new and complex GML schemas.  Need to deploy large geospatial datasets at home or in the clouds?  Think about getting a GML heart.  It could be the easiest thing you have ever done – and nary an angle bracket in site!