These comments are from Martin Daly, Technical Director at Cadcorp, Mark Millman, president of Millman and Associates (who was most recently at Bentley), and Frank Warmerdam an independent "geospatial programmer for hire."

First up, Martin Daly:

"I want to take issue with Bart van den Eijnden's comments on GML in [last week's] GIS Monitor, on two points.

"Firstly, the responsiveness of a single open source developer versus that of a single closed source vendor does not imply that all open source developers or closed source vendors are alike. Or, to use my new favourite quote: 'The collective noun for anecdotes is not 'data.''

"Secondly, while I have the utmost respect for Frank Warmerdam and his body of work, have worked with him closely in the past, and look forward to doing so in the future, he has not, by any stretch of the imagination or by his own admission, developed a generic GML parser. By that I mean a parser that can, upon being given a GML instance document for the first time, and, with no human intervention and no extra configuration files, parse and 'understand' the XML Schema upon which the document is based, finally extracting the GML 'features.'

"Such parsers are not quite as rare as hen's teeth, but close. I know of ours at Cadcorp, and those developed by Galdos, Snowflake Software, and Safe Software. There may be others. I am not implying that Frank could not develop one of these if he wanted to. In fact I am sure that he could should he want to and, as can sometimes be crucial for open source developers, had funding to. It is just that he hasn't so far. The high cost of developing such a parser perhaps explains why they are so rare, why WFSs don't always interoperate, and why a GML 'profile' may be desirable in order to lower the entry barrier to GML parsing.

"Because we at Cadcorp are saying that we can parse any GML 2.1.2 document, we are from time to time sent documents and/or links to WFS requests that don't load into Cadcorp SIS. This is usually a problem with the document itself, or the XML Schema that it is (or often purports to be) based on. It can also be a problem with XML Schema files no longer existing, or not being where they once were. These are perhaps more reasons for a GML 'profile,' this time lowering the barrier for writing GML, rather than for parsing it."

Next up, Mark Millman:

"GML is a vast abstract meta-data language that can be used to describe almost any concept in 2D or 3D (or even 4D) space. The authors have retreated to fundamentals (including building a novel mathematical model for coordinate systems) that are independent of common practice. To this extent it is brilliant. However, the very power of GML is its own downfall. I would suggest that a literary parallel would not be the English language but the Western Alphabet. The idea that GML can act as a universal repository is, from an implementation point of view, very difficult. While accepting the fact that ESRI chooses to implement a narrow GML Profile (essentially the Shape File protocols in GML) the idea that [the company] could have created a reader that would consume any valid GML data set without significant user involvement is a fantasy.

"This problem was openly discussed during the meeting [GML Developer Days] and it was generally acknowledged by the legacy vendors that what was needed was a small subset of GML that they could all agree to support. Even the existing implementers of GML repositories (U.S. Census, Ordnance Survey (OS), etc.) agreed that they could not read each other's data.

"I have great sympathy for the GML effort and believe that it is a valid and worthwhile effort but I have come to believe that, like the OGC itself, [it] may be too late. To be successful standards must come in to being early in the evolution of a new technology. Once a market has matured, and I believe that the GIS market is well past the emergent phase, standards face an insurmountable task of unseating market leaders. This is not specific to GIS, it is just as true for televisions. We still don't have a world standard for televisions! Compare this to computer monitors. The global demand and international manufacturing opportunities for monitors were recognized early enough that vendors banded together to create common standards when the industry was just beginning.

"I sympathize with ESRI on this matter. [The company is] legitimately concerned about supporting an interface that is robust and useable (e.g. not too complex). To this end [ESRI] has chosen to use [its] shape model as the basis for interoperability. My experience tells me that to do more would be a developer's black hole that would significantly detract from the progress of the core product line. This is true not just for ESRI but for all legacy GIS vendors.

"My prediction is that major data providers, including the U.S. Census, OS, and others will create GML data profiles, sometimes with non-compliant extensions (i.e., the OS), and that major vendors and translator folks (like Safe Software) will read and write those profiles.

Finally, Frank Warmerdam:

"I agree with what Martin [Daly] says.

"I just want to stress the point that, while difficult, it is possible to write good, general GML readers. I think software buyers should demand good GML support from their vendors including a sensitivity to the needs of practical interoperability and responsiveness in fixing issues promptly.

"I don't think the issue at hand is one of proprietary vs. open source software. Rather it is about frustration in the face of software vendors who don't seem motivated to achieve practical standards based interoperability in a timely fashion."