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

Maciej Stachowiak wrote:
> 
> 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.

It is my belief that if a new syntax would be proposed, it would end up 
being yet *another* syntax to be supported.

The spirit of my proposal is to see if there are any new APIs needed, or 
if any of the existing APIs should be modified in order to help tools 
which intend to mine content which contains what I will refer to as a n 
"xmlns inspired" syntax in the context of HTML.

Given Phillip's document referred to in:

http://lists.w3.org/Archives/Public/public-html/2009Oct/0067.html

The current HTML5 Working Draft proposes:

1) IE, Firefox, and Safari to change what they return for nodeName.
2) IE and Firefox to change what they return for localName.
3) IE to change what it returns for prefix.
4) IE, Firefox, and Opera to change what they return for namespaceURI.

Tony's proposal:

1) IE, Firefox, and WebKit to change what they return for nodeName.
2) Firefox, Opera, and Safari to change what they return for localName.
3) Firefox, Opera, and Safari to change what they returns for prefix.
4) IE, Firefox, and Opera, and Safari to change what they return for 
namespaceURI.

While it is worth noting that nobody has proposed changing what the 
results of parsing documents served as XHTML returns, Tony's proposal is 
to close rather than expand the gap between the processing of HTML and 
XHTML.

Additionally, there may be merit in discussing whether or not tagUrn 
should be documented and implemented (perhaps in a separate spec, and 
perhaps only in JavaScript in some implementations).

> Regards,
> Maciej

- Sam Ruby

Received on Saturday, 3 October 2009 13:24:01 UTC