This post originated from an RSS feed registered with Ruby Buzz by . Original Post: Not Solving Problems Feed Title: cfis Feed URL: http://cfis.savagexi.com/articles.rss Feed Description: Charlie's Blog Latest Ruby Buzz Posts Latest Ruby Buzz Posts by Latest Posts From cfis

Bryan Lawrence has an interesting response to my post about integration and GML. In his view, GML is not meant for data exchange but instead provides a common language that various communities can use to develop interoperable solutions. He fully understands that this adds complexity to the problem, but in his opinion the extra complexity pays dividends in the long run. To quote:

On the way we can write a new descriptive language every time (for every pair of new communities), or we can try and design an abstract descriptive language that allows one to avoid that step every time someone wants to interoperate. Doing the latter introduces considerable complexity...But, and here is the big BUT, unless you know you will never want to share your data, then you've just moved that complexity til later, you haven't undone it.

I am sympathetic to his argument - I used to hold the same view point. But over the last few years I've changed my mind for the following reasons:

First, I don't think the cost of the additional upfront complexity is ever recouped. If I want to share data with my business partners, I can invent and implement a proprietary exchange format in less time then using GML. Or take an even simpler route - just exchange shape files and be done with it.

Second, with this approach you end up with thousands of separate communities that cannot exchange data between them. Whether this is good or bad depends on your goals - if I want to exchange data with a few other like minded organizations then this is ok. But if your goals are loftier, to create a world-wide geoweb, then this is bad.

Third, if the goal really was to create a common language to describe geographic information, as opposed to exchanging it, why not reuse UML (Universal Modeling Language) by creating a UML profile?

What Problem Are We Trying to Solve?

Brian finishes by saying:

I wish folk wouldn't keep on arguing that just because some technology doesn't solve their use case it's flawed!

I absolutely agree - no technology can solve every problem. In the case of GML, it obviously boils down to what problem you think it solves. Is it meant to make it easier to implement thousands of one-off data integrations, or is it meant to enable geographic data exchange on a world-wide scale?

If its the former, then I think there are simpler, faster approaches than GML. And if its the latter, then GML fails to provide a simple format that every system can use in the same way that Atom does.