- From: Maciej Stachowiak <mjs@apple.com>
- Date: Sat, 03 Oct 2009 05:50:34 -0700
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Sam Ruby <rubys@intertwingly.net>, Adrian Bateman <adrianba@microsoft.com>, HTML WG <public-html@w3.org>, Tony Ross <tross@microsoft.com>
On Oct 3, 2009, at 2:31 AM, Julian Reschke wrote: > Maciej Stachowiak wrote: >> ... >> That is true. >> Is it ok that in an XML document, the API would give different >> answers than the built-in XML namespace mechanism? Would it be >> acceptable to encourage consumers to process XML content based on >> "effective namespace URI" instead of based on actual Namespaces in >> XML processing? > > ... > > I would hope that that API gave the same answers for XML documents, > and would only differ in HTML. Sam suggested an API that is implementable in pure ECMAScript (presumably it works by looking at ancestor elements to find namespace declarations). That would not give the same answer for an XML document as namespaceURI. > >> I suggest that if we introduce a mechanism with different behavior >> than either Namespaces in XML or IE's HTML namespaces, but usable >> in the same document at the same time, then it should probably use >> a different syntax than Namespaces in XML. >> ... > > If Microsoft is willing to *change* their namespace support in HTML, > and nobody else is implementing it, then I don't see why a new > syntax would be needed. Sam proposed a mechanism that would do namespace binding in a way that requires no browser support at all and can be implemented in client- side script if needed. I think it's better for a mechanism like that to use a separate syntax, so there's no risk of interpreting namespaced content in two different ways. Or maybe three different ways, if IE's model, Sam's proposed new model, and the XML model may all apply. Regards, Maciej
Received on Saturday, 3 October 2009 12:51:09 UTC