Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: RE: James Clark: XML versus the Web
 My experience with DOM came about in late '98, when Microsoft was beginning to explore the XML space with early prototypes of XSLT, schema and DOM. I was writing one of the earliest programmatic books on XML, though that was only evident in hindsight. The technology (DOM) was fairly radical for its time, trying to provide a set of interfaces for integrating XML with other languages - especially given that the XML spec itself was still largely evolving "away from" SGML at the time.
DOM's primary role was to act as an interface for other languages to work with XML, and even back then, Microsoft included as part of its DOM API the selectNodes() function which was provided as a way to invoke XPath, because it was seen as a more effective way to retrieve information than DOM for a fairly significat class of operations.
Unfortunately, shortly thereafter, Microsoft ended up making a fateful decision to put more resources into the server side of the business than the client side (a decision that I suspect originated with Ballmer, who never really did have much of a feel for client side tech and who was beginning to take over a lot of day to day operations from Gates). That was also also about the time that Netscape imploded and the DOJ begin antitrust hearings into the space that effectively froze out client development altogether (which was also one of the reasons that IE6 stayed frozen for six years).
A frozen IE meant a frozen DOM, which also meant that some of the more innovative ideas (such as the useful but ill-named XMLHTTPRequestion object) were effectively ripe for the picking because Microsoft was simply not interested in defending them. It also meant that DOM became the preferred mode of manipulating HTML content (and XML) because it had become stable (why reinvent, when there was a perfectly good "standard" there for the taking and that was not going anywhere).
Another factor that played into DOM's rise and fall in the XML space was ultimately that the interfaces that the W3C did adopt (especially with regard to later DOM development) were overspecified and cumbersome. XPath access in particular was made inaccessible - the preferred mechanism (and the one that Microsoft, in an attempt (for once) of trying to comply with standards made a mistake on with .NET, was to abandon the easy to use selectNodes() function for a process using an XPathEvaluator, NamespaceResolver, XPathExpression and XPathResult. In most cases, I usually ended up rebuilding selectNodes() from these pieces because it was just too much of a pain in the butt to use XPath otherwise, but I suspect that a lot of the disdain that web developers had for XPath originated in part because of that hideous set of interfaces. Unfortunately, once you make XPath inaccessible, then it becomes a much harder sell to explain why anyone would want to work with XML in the first place.
I've rediscovered a lot of the joy I used to have with XML in working with XQuery, where there is nary a DOM object to be found, but the damage has been done for a lot of developers. Kurt Cagle XML Architect Lockheed / US National Archives ERA Project On Tue, Dec 7, 2010 at 12:26 AM, Gavin Thomas Nicol <gtn@rbii.com> wrote:
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
