[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
Re: [xml-dev] RE: James Clark: XML versus the Web
- From: Kurt Cagle <kurt.cagle@gmail.com>
- To: Gavin Thomas Nicol <gtn@rbii.com>
- Date: Tue, 7 Dec 2010 19:34:53 -0500
Gavin,
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:
> DOM was necessary at the time - you needed a way for external languages to
> have low level access to XML in order to create tools (such as XPath,
> XQuery, E4X, etc.) that provided higher level accessibility. The problem was
> that rather than build XPath or E4X like layers into the browsers, the
> browser implementers took the DOM spec as the baseline for working with XML,
> and it took years for any kind of advanced technology to work its way into
> even a few of the systems (and that often badly).
That's actually more or less ass-backward. DOM came from trying to take what browsers *did* do and shoehorn it into something that could possibly work with XML and HTML. Most of the idiocy existed *before* the DOM WG even had a spec. or was foisted off onto the WG later in the game.
The DOM was actually successful in that it gave birth (albeit painfully and over a long period of time along with cohorts like ECMAScript) to a relatively standard programming environment in the browser that then led to all kinds of things, including, ultimately JSON, AJAX et al. More than anything else, the DOM effort was about creating a standard *browser* API, not a standard *document* API. The "Document Object Model" is a misnomer.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
