Defeating XML & GML (Part 1/2: Conquer the Fear)
During the FME 2011 World Tour I had the opportunity to share my excitement and love of XML and GML. One of the things that I discovered on the road is that many users I met with absolutely dread having to work with XML and GML. I was only too happy to share the good news that you do not need to fear XML or GML.
[A note about GML: I won’t mention GML again in this post (for brevity) as GML is XML with predefined primitives that help represent spatial data in standard ways. So if your passion is GML, then simply read GML everywhere where I say XML. The story remains the same.]
Reasons for the Fear of XML
One of the reasons for this fear is that, until recently, working with XML required users to learn technology that is specific to working with XML. The tools are typically open source XML tools such as XQuery or XSLT, and/or XML tools from other vendors. Learning new technology is an investment in time and/or money, thus making adoption expensive.
If I had to learn XQuery or XSLT in order to work with XML, I would not be excited about XML, as I don’t have the time to learn and master these tools. What I am excited about is giving people tools to work with XML without them having to learn XML-specific tools, or be fluent in XML.
The Spatial Alternatives to XML
If XML is so scary then what are the alternatives to sharing data with XML in geospatial?
Is it better to share data using vendor or application-specific binary formats? Many of these “formats” are not data formats but application-specific formats that were designed to support a particular application. They are often undocumented and thus poor candidates for data storage.
Is it better to share data using formats like Excel, CSV, or Esri Shapefile? The biggest thing going for these formats is their simplicity. While there’s a lot to be said for keeping things simple, these formats were either not designed with spatial data in mind or (in the case of Shapefile) are showing their age. These formats also do not lend themselves to the storage of other important information such as relationships between objects/entities, and have no support for metadata.
Why XML Trumps the Alternatives
On the other hand, XML is an expressive open standards based approach to sharing all kinds of data. As the name suggests XML (EXtensible Markup Language) is not a format but rather a language for defining formats (i.e. how data is to be shared). This expressiveness enables XML to store all types of data that spans many different communities and industries. It is capable of representing both the very simple and the very complex.
I am excited about XML as it is capable of representing all types of data. Solving the XML challenge thus opens up the whole world of data.
XML isn’t Hard. Data Models are Hard.
Is XML itself hard? Or, is what’s hard trying to understand some of the data models that are created using the freedom of XML? I would argue that it is more the data models that are hard. Regardless of your view on this situation there do exist many XML data models that are very complex indeed – some needlessly so.
Remember, the more complex that the data model is, the more effort there is that’s required to use it, and therefore the less data exchange that will be happen. Given data in a needlessly complex model and the same data in a simple model – the simple model has more value!
I am excited about the new solutions under development that will make working with XML even easier. The future of XML is bright with more and more data of all types being shared in XML.
As XML grows in importance (more about that next week) and tools are released which remove the need for users to learn XQuery, XSLT, etc – there’s no longer any reason to fear XML.
Next week, I’ll talk about the future of XML and invite you to participate in the XML Challenge. For now, watch a video of the XML presentation I gave in March 2011. Or, tell me your opinion about XML and GML. What do you love or hate about XML? Is XML hard to work with?