Fwd: [xml-dev] Re: Native XML Interfaces

["Timothy W. Cook" <timothywayne.cook@gmail.com>]

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