- From: Noah Mendelsohn <nrm@arcanedomain.com>
- Date: Mon, 20 Dec 2010 15:33:37 -0500
- 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 UTC