- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 29 Jul 2008 20:07:19 +0000 (UTC)
- To: Sam Ruby <rubys@us.ibm.com>
- Cc: HTML WG <public-html@w3.org>
On Tue, 29 Jul 2008, Sam Ruby wrote: > > My point isn't that these issues are similar (they are not, nor are the > issues of predictable error recovery and namespace prefixes, for that > matter), just that issues aren't always all-or-nothing. It might turn > out that namespace prefixes in a few well defined places is possible, or > that the predictable error recovery currently specified can be tweaked > (while still retaining the quality of being predictable). The difference here is that even providing namespace prefixes is undesireable regardless of whether it can be made to technically work, whereas allowing the trailing solidus talisman was a net benefit if allowed in a small set of well-defined cases. > My larger point is that there is a spectrum between the full-on bells > and whistles approach to XML namespaces that was explored and rejected a > half a decade ago and a no-namespaces, no-how, under no circumstances > approach to namespaces that was present in HTML5 a mere few months ago. > And exploring the solution space for the potential of small movements > along that spectrum should not require "radical new evidence". The specific issue that I said required "radical new evidence" was the assumption that namespace prefixes acting as indirection syntax for namespaces was a bad design. That's pretty much unrelated to the rest of what you are talking about. So I believe you are actually arguing at cross-purposes here. HTML5 as it stands now does straddle the spectrum of possible approaches to multiple vocabularies, supporting as it does vocabularies from two different namespaces (three if you include the SVG stuff in the comments). I've personally looked carefully at a huge number of possibilities for introducing namespace syntax of various kinds (e.g. using xmlns:prefix="", xmlns="" only, introducing htmlns="", having predefined keywords instead of URLs, having special syntax, you name it), and concluded that actually supporting author-declared namespaces isn't a good design, or that, at least, I haven't seen a good design for it. I've sent many e-mails on the subject, discussing the pros and cons of each individual proposal I've seen and providing links to sample pages that are affected by each proposal, and so forth. This certainly isn't a firm assumption like the namespace prefix issue, though. If new proposals come forth (such as the SVGWG's), then I will make sure to study them carefully too. (I haven't yet studied the SVGWG's in depth; I am hoping that the SVGWG will address the points Andrew, Henri and myself have raised before I do so.) Now, if you have a specific proposal, then I'm very happy to hear it. But there's not much point suggesting that such proposals aren't being considered, since that's not true. Please read exactly what I write, and don't respond to straw men arguments that aren't what I wrote. In this case: http://lists.w3.org/Archives/Public/public-html/2008Jul/0352.html ...I pretty clearly state that "the assumptions that namespace prefixes are bad ... are both assumptions that we have taken as fundamental in the HTML5 work since 2003". I don't talk about all mechanisms for mixing vocabularies. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 29 July 2008 20:07:59 UTC