Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Fwd: Re: Native XML Interfaces
 An very interesting (for me) thread. A lot of good historical information. What I find conspicuously missing is commentary about XForms in all of this. I would be very interested to hear from all of you in this context. Thanks in advance for sharing your insights. --Tim On Sat, Jun 1, 2013 at 2:34 AM, Kurt Cagle <kurt.cagle@gmail.com> wrote: > Lauren, > > 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 > kurt.cagle@gmail.com > 443-837-8725 > > > > 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. >> >> Lauren > > -- ============================================ Timothy Cook, MSc +55 21 94711995 MLHIM http://www.mlhim.org Like Us on FB: https://www.facebook.com/mlhim2 Circle us on G+: http://goo.gl/44EV5 Google Scholar: http://goo.gl/MMZ1o LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook 
[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
|
|||||||||
