OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Re: Native XML Interfaces


Sadly, I think that even many in the HTML5 community lost sight of the real goal for DOM. I've described DOM to clients as a mechanism whereby different languages communicated with the conceptual layer of the HTML page. XPath (and its derivatives) could have readily supplanted it, as JSONiq, XQIB and Saxon-CE all illustrate quite well, save for a couple of engineering (and political) problems. 

The engineering problem was the need to start rendering a document before it had been fully loaded, which ironically would have been resolved simply by treating a sequence of nodes as a valid HTML input, instituting a rule that if an element with the same id was encountered in the stream it would replace any previous node with that id, and eliminating the idea that a document "ends". It would have effectively annulled the need for AJAX, and would have significantly reduced the need for JavaScript in the first place. A "new" document would then simply have been accomplished by passing a <page> element to the client, layout containment would happen either by syntactic containment or by reference, and script bindings on new elements would only be enforced when such an element was created or replaced.

The political problem was the need for DOM in the first place. DOM was seen by many as a way to make HTML understandable to programmers who were used to working with imperative languages, and as such it was an adoption issue.

I see a lot of that thinking in HTML5, one of the reasons I think that the language is ultimately a failure. When HTML 4 was standardized, the need for a consistent set of features was very high, and so the incorporation of standard tags that performed core functions declarative made sense. In HTML 5, the need was no longer really there, while the need for providing a consistent mechanism for extensibility was critical - JavaScript and jQuery have effectively become sufficiently fast and powerful that adding new functionality into the browser via tags is now feasible. Indeed it's at the heart of every JavaScript binding of a <div> or <span> element to turn those generic block and line regions into containers for behavior. Instead, there were bitter arguments about the utility of <hgroup> or <nav>, whereas things that would have had far more use - such as a <linkBlock> element that would have been a container for search result link+metadata - were ignored because they didn't fit the 1990s retro vision of what the browser should be that WHATWG arbitrarily chose.

Now, after the fact, things like Web Components and Shadow Trees seem to finally be making their way into the specification, though I fear that much like XBL before them, these standards will be met with a cold reception by the browser vendors. I hope I'm wrong - I think that in many respects it will be experimentation about the nature of the HTML standard itself that will drive the evolution of the web.

Kurt Cagle
Invited Expert, XForms Working Group, W3C
Managing Editor, XMLToday.org

On Fri, May 31, 2013 at 9:08 PM, Lauren Wood <lauren@textuality.com> wrote:

On Fri, May 31, 2013 at 7:45 PM, Liam R E Quin <liam@w3.org> wrote:

Standards bodies are not really needed until there are multiple
implementations and a spec is in demand by users. Vendors benefit from
incompatibilities until the users insist on standards.

Which was the case for the DOM way back when, or has everyone forgotten the browser wars? IE, Netscape, HotJava, Spyglass, etc, and the expected path forward at the time of the big web bubble was for HTML to expand using XML, allowing for proprietary features in a standards-compliant way. The biggest issue the DOM WG faced was trying to reconcile the browser HTML read-only view of the world with the XML document editable view of the world with the XML and SQL database view of the world.

Standards in their first version are stepping-stones to the next related standard - SGML to XML being the oft-quoted example, or DSSSL to XSLT/XSL-FO, although HyTime to XLink didn't quite pan out. SAX and DOM were the first widely-implemented XML APIs and as such should be be considered as explorations as well as attempts to standardize at least some part of the solution to some problems. I disagree that the DOM failed. There are certainly many parts of it that some of us on the DOM WG even at the time wanted to change but couldn't, but it standardized part of what needed standardizing, for HTML even if not to the level that many XML people would have liked.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS