February 25, 2004
@ 12:16 PM

In his post JDOM Hits Beta 10 Jason Hunter writes

According to my Palm Pilot calendar, we laid out the vision for JDOM on March 28th, 2000. I figure we'll ship before March 28, 2004. If we can ship 1.0 before it's been a full four years, I can just round down and call it three. :-)

What took it so long? Several things. I discovered XML is "fractally complex". At the highest level it appears only slightly complicated, but as you dig deeper you discover increasing complexity, and the deeper you go the more complicated it continues to become. Trying to be faithful to the XML standards while staying easy to use and intuitive was a definite challenge.

This is one of challenges I face in my day job designing XML APIs for the .NET Framework. The allure of XML and its related technologies is that they appear simple and straightforward but once one digs a little it turns out that everything isn't quite as easy as it seemed at first.

One of the drawbacks of this appearance of simplicity is that everyone thinks they can write an XML parser which leads to occurences such as what is described in this post by Shawn Farkas Creating a SecurityElement from XML  

The overhead of a full-fledged XML parser would be too much. Even if you accept the fact that we need a lightweight security XML object, we can't even provide utility methods on SecurityElement to convert back and forth System.Xml objects, since the CAS code lives in mscorlib.dll, and mscorlib cannot take a dependency on external DLL's. (Think of what would happen if mscorlib depended on System.Xml.dll, and System.Xml.dll depended on mscorlib ...). As if this weren't enough, there are at least 3 distinct XML parsers in v1.1 of the framework (System.Xml, SecurityElement, and a lightweight parser in mscoree.dll which handles parsing .config files ... this was actually optimized to be able to fit into no more than two pages of memory). Whidbey will be adding yet another parser to handle parsing ClickOnce manifests

One of the things I'm currently working on is coming up with guidelines that prevent occurences like System.Security.SecurityElement, a class that represents XML but does not interact well with the rest of the XML APIs in the .NET Framework, from happening again. This will be akin to Don Box's MSDN TV episode Passing XML Data in the CLR but will take the form of an Extreme XML article and a set of .NET Framework design guidelines.


Wednesday, February 25, 2004 1:43:40 PM (GMT Standard Time, UTC+00:00)
Maybe the parser (XmlTextReader, that is) should be more open and customizable... just an idea... (a bit more like Xerces)
Wednesday, February 25, 2004 2:25:32 PM (GMT Standard Time, UTC+00:00)
>The allure of XML and its related technologies...

I have long thought that the "simplicity requriement" of xml is the reason that its related technologies are such a pain in the butt. xml itself is surface simple by design, but for it to become "all things for all people" the related technologies have to serve many masters. This results in things like xslt, while not super complex, is certainly more complex than a more robust data naming system with transformations built into the core technology set would be.

My concern with xml is that the simplicity and usefulness of the core technology as an enabling technology for other things like config files for web and windows applicatios will be compromised by the necessary complexity to make xml and its satellite technologies solve very complex problems.

You have a tough job. You have to enable the tough-problem crowd to solve their issues while supporting the greater majority who will be just want a fast and light config file parser.
John Morales
Wednesday, February 25, 2004 7:31:16 PM (GMT Standard Time, UTC+00:00)
I'm not sure what you mean by 'more open' but the XmlReader will be more customizable and allow developers to select which options they want in the XmlReader they create. This is similar to setting XML parser features in JAXP such as is described at http://xml.apache.org/xerces2-j/features.html
Comments are closed.