Re: HTML/XML Task Force Minutes 18 January 2011

Sam (and to the members on the list at large),

My intent was not to be critical of the work being done here (I'm trying,
really! (and read that as you will)). I *am* saying that I think that a lot
of the HTML5 specification, and comments from people on this list and
elsewhere, has placed a definite emphasis on the relevance of HTML5 over
that of the XML portion of the specification and whether the implications
that it IS an XML document gets lost in HTML5 considerations of the
document. Additionally there have been a number of attempts to dismiss
technologies such as XForms (and others) that apparently have no role in the
HTML5 vision but that nonetheless are very real use cases for organizations
which have invested heavily in XML production pipelines. My interest in this
process is to assure that these use cases (and the organizations who have a
stake in them) don't somehow get shoved under the rug.

I don't believe this is an unreasonable position to take. I worked with a
number of SVG groups half a decade ago trying to get SVG adopted into the
browsers, despite (at the time) fairly strong opposition from those browser
vendors who felt that the future was Canvas, and declarative XML markup
really had no place there. It's a feeling I suspect is still felt by members
within this core group to some extent. It took SVG coming in through the
backdoor (such as its use in Linux distributions) and sufficient outcry from
people who had believed that this technology WAS the way forward to get to
the point where browsers began to experiment with it, and only now, a decade
after the specification was published, is SVG finally native in all the key
browsers (IE9 being the last). Uptake in SVG usage is beginning to climb,
though again it will be those organizations that are willing to make the
jump and support new browser tech that will be at the forefront of that.

Let me say this up front, just to get my position on this clear - there is a
lot of innovative work that's been done by the HTML5 working group, and
overall, I think the things that have been added to the specification are
things that were long overdue and should make for both improved development
processes and for a better user experience. You should rightly be proud of
what you have done. However, this experience, and the intensity of feelings
that this has engendered about certain technologies, may very well also
color your impressions with regard to technologies that may be seen as
either competitive (XForms vs. Web Forms) or irrelevant (MusicML, XSLT). I
have to temper my own opinions in that same regard - I've invested as much
of my career in XML related technologies as most of you have with HTML (and
some have both), and naturally will have my own biases as well. I'm trying
to do just that.

The critical question with this task force is in ascertaining where the role
of HTML stops and XML starts. This becomes problematic in places such as
XForms, which as a technology started with one mission - providing a way of
improving the HTML 4 form layer - and evolved into another - finding a way
of providing an XML context for working with XML content within the HTML
browser. It's likely not the only solution to this; XQIB I think is an
innovative approach that may work as well, and the two technologies are not
incompatible. I don't think that anyone in the XForms working group feels
that the original mandate is really as relevant any more - AJAX also filled
that niche, providing a layer (one that's becoming standardized) for working
with information at the atomic rather than the data-model centric viewpoint,
the way that a lot of developers (but not all by any means) seem to prefer
it, but it turns out that XForms works remarkably well with other XML client
technologies.

The question I would address to Sam (and to anyone else interested in
answering it) is whether XHTML5 does indeed fit the requirements of the XML
world, not as a schema, but as interpreted within the browser. I'm in a
minority here, and not a member of the task force, just an observer with a
stake in the answer. If it does, if I can be guaranteed that I can build my
XForms apps within XHTML5 without it breaking, if I can be assured that I
can extend the browser with an XBL or some similar mechanism to be able to
handle a MusicML or similar language format, then I'll happily use XHTML5
over HTML5, because that's where my workflows are (and the workflows of a
lot of other organizations worldwide), and won't raise much of a stink that
HTML5 mauls my XML content, because I won't be using text/html as my
mime-type. To that end, however, I want to make sure that the XHTML5
implementation is as robust as possible in an XML sense, not just in an HTML
one.

That's a part of the reason that the issue about XML and HTML compatibility
needs to move beyond talking about the particular parse order of empty
elements, because the HTML5 assertions have implications - within scripting,
for extensibility, for binding, for rendering, and elsewhere within the web
browsing model. I recognize - I think most everyone here should recognize -
that the incompatibilities will remain, because both sides have legacy
systems that strongly limit the degree of change that can be made, and
because the emphasis in HTML is on permissive parsing (out of necessity
given its base) just as the emphasis on XML is strict parsing (out of
necessity given ITS base) - these are contradicatory. The question thus
shifts up the stack to where in fact compromise can be reached. I'm not
quite sure where that is, though I feel that the HTML5/XHTML5 division is
probably a good place to start.

Apologies if these comments give offense.


Kurt Cagle
XML Architect
*Lockheed / US National Archives ERA Project*




On Fri, Jan 21, 2011 at 10:27 AM, Sam Ruby <rubys@intertwingly.net> wrote:

> On 01/21/2011 09:01 AM, Kurt Cagle wrote:
>
>>
>> I think one of the bigger concerns that I have with the HTML5 effort is
>> that XHTML5 tends to be addressed as an afterthought
>>
>
> [citation needed]
>
> I suggest that these types of assertions have no place here.  There are
> clearly people in the working group with strong ideological bents.  That
> being said, HTML5 is being defined by those who actually chose to
> participate.
>
> http://www.w3.org/html/wg/#join
>
> - Sam Ruby
>