- From: Sam Ruby <rubys@intertwingly.net>
- Date: Thu, 19 Nov 2009 12:03:53 -0500
- To: Liam Quin <liam@w3.org>
- CC: Boris Zbarsky <bzbarsky@MIT.EDU>, public-html@w3.org, public-xml-core-wg@w3.org
Liam Quin wrote: > On Thu, Nov 19, 2009 at 11:00:19AM -0500, Sam Ruby wrote: >> A more relevant question would be: what is Liam's intent? Having talked >> to him at TPAC, I gather that he would like to see an XML' (read as: XML >> prime) which differs as little as possible from the current XML >> recommendation but is somewhat more suitable for a (possible niche) set >> of use cases that he doesn't perceive HTML5 satisfying. > > Sam, thanks for steering the ship back onto course. > >> If I understand Liam's intent correctly, I believe that such entails a >> lot of work: a lot of specification, a lot of advocacy, a lot of coding, >> and lot of testing, etc. > > I hope not. I'll restate my original goals -- it might be that > they don't align with the "distributed extensibility" topic. > Certainly I did not intend to open the door to changing XML to allow > silent error recovery as part of this proposal. > > 1. Make it possible to serve XHTML as text/html in such a way that > HTML and XML processors end up with the same interpretation of > the document as HTML documents, even in the presence of "svg" and > "math" elements. It already is possible to serve a subset of XHTML documents as text/html in such a way that HTML and XML processors end up with essentially the sam interpretation of both documents, even in the presence of "svg" and "math" elements. Such a subset does not, in general, include inline script elements. There are quite a few other differences too. If your goal is to not have it be a subset, then suffice it to say that I'm skeptical. Very skeptical. > I have proposed "Unobtrusive Namespaces" as a mechanism > for XML processors outside Webbrowsers, and "Imaginary Namespaces" as > a mechanism to describe how HTML 5 Web browsers actually work. > If accepted, there would be no code change for a Web browser to > support Imaginary Namespaces. There would, however, be a > namespace definition file that would be part of the HTML 5 spec > (I hope as an external file referenced by the spec, though). So, unless I'm misunderstanding, your goal with #1 is to increase the subset by reducing the need for xmlns "talismans", and offsetting this by a requirement for a side file. > 2. Make "namespace mashups" and user-defined namespaces possible without > the need for, or with a reduced need for, the existing XML > namespace syntax. This is bring the XML "Unobtrusive Namespaces" > proposal into Web browsers, and is an attempt to address > disrtibuted extensibility in HTML/Web user agents. > This part would indeed require coding and testing, although > "a lot" is subjective. > > I hope this is clearer. I'll see what I can do with regard to > a prototype of unobtrusive namespaces (and anyone who can help > with that feel free to contact me, I'm pretty maxed out for > the next 2 weeks, despite officially being on vacation...) From my perspective, this is a set of modest improvements (that may or may not be doable or worthwhile: I'm not making value judgments here), that fall well short of the stated goal of "Make it possible to serve XHTML as text/html in such a way that HTML and XML processors end up with the same interpretation of the document as HTML documents". > Liam - Sam Ruby
Received on Thursday, 19 November 2009 17:04:35 UTC