W3C home > Mailing lists > Public > public-html@w3.org > October 2009

Re: ISSUE-41/ACTION-97 decentralized-extensibility

From: Maciej Stachowiak <mjs@apple.com>
Date: Sat, 03 Oct 2009 05:50:34 -0700
Cc: Sam Ruby <rubys@intertwingly.net>, Adrian Bateman <adrianba@microsoft.com>, HTML WG <public-html@w3.org>, Tony Ross <tross@microsoft.com>
Message-id: <1BB298E7-9F1A-4EE4-994F-1198A09AA97D@apple.com>
To: Julian Reschke <julian.reschke@gmx.de>

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.

Received on Saturday, 3 October 2009 12:51:09 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:52 UTC