W3C home > Mailing lists > Public > public-html-xml@w3.org > December 2010

Re: What problem is this task force trying to solve and why?

From: Noah Mendelsohn <nrm@arcanedomain.com>
Date: Mon, 20 Dec 2010 15:33:37 -0500
Message-ID: <4D0FBDA1.40200@arcanedomain.com>
To: David Carlisle <davidc@nag.co.uk>
CC: Henri Sivonen <hsivonen@iki.fi>, public-html-xml@w3.org
I won't be able to join on tomorrow's call, so let me offer a few thoughts 
here.  I agree with many of the bits and pieces expressed in this thread, 
but overall, I'd suggest we focus the discussion a little more on:

* What is desirable in terms of use cases?  I.e, what is it that various 
constituencies want to do, but can't do with the current specs and tools?

* What sorts of changes are likely to be deployable and widely adopted in 
practice.  That question applies equally to HTML as to XML, and the answer 
in both cases may be: few or none.

Those two questions aren't entirely independent:  there are inconvenient 
changes that the community may adopt over time, if the value is compelling, 
but that otherwise would be impractical. Still, we're at great risk of 
spending lots of times on things that wouldn't get deployed in practice.

The "constituencies" and use cases I think we should consider include: 
content creators, including those building tool chains and validating 
content; content management systems; browsers; search engines; other 
non-browser user-agents.

A few other thoughts:

* Being liberal in what you accept has arguably proven useful on the Web, 
but we may offer better value in helping users to be conservative in what 
they send.  FWIW:  I find that XML validation of my (X)HTML sometimes trips 
on errors I wouldn't need to fix in practice, but often it catches errors 
that would cause a browser to skip significant content when rendering.  So, 
I find XML validation to be valuable;  maybe or maybe not a good HTML5 
validator would meet the need instead.  Anyway, I think we need to think 
about the right mix of XML and HTML validation, in cases where users wish 
to ensure that generated or hand-authored content is correct.

* Polyglot keeps coming up:  I think we should start by trying to clarify 
who would benefit from more robust polyglot capability, and what they need. 
  Then we can get to particular technical features of the languages that 
might need attention.

* Distributed extensibiity, and the ability to mix arbitrary XML 
vocabularies into HTML, are related capabilities, and there seems to be 
disagreement in the community as to what's desirable as well as on what's 
achieveable in practice.  FWIW: my TPAC 2009 attempt to summarize the 
various positions and concerns is at [1,2].

* I think that there are misunderstandings about the need to stop on first 
error in dealing with XML, and I'm hoping to do a blog post setting out 
some thoughts on that.  When/if I do, I'll send a link.

I hope the above is some help in preparing for tomorrow's call.  In short, 
let's drive this by use cases and what's achievable in practice, not 
(mainly) by technical desiderata.

Noah

[1] 
http://lists.w3.org/Archives/Public/www-archive/2009Nov/att-0004/DecentrailzedExtensibilityandHTML_v9fixed.ppt
[2] 
http://lists.w3.org/Archives/Public/www-archive/2009Nov/att-0004/DecentrailzedExtensibilityandHTML_v9fixed.pdf
Received on Monday, 20 December 2010 20:34:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 20 December 2010 20:34:07 GMT