Re: Distributed Extensibility

Henri Sivonen wrote:
> On Aug 5, 2007, at 22:42, Philip Taylor wrote:
> 
>> producing an element with name "fb:dashboard" in namespace 
>> "http://www.w3.org/1999/xhtml".
> ...
>> Tools which feed into an XML pipeline can do whatever they want for 
>> mapping certain elements into real namespaces.
> ...
>> I expect this may be insufficient, but in what ways?
> 
> The main problem is that parsing in text/html browsers and parsing in 
> server side systems working on XML 1.0 plus Namespaces infosets would 
> diverge and that the DOM in text/html and application/xhtml+xml browser 
> code paths would diverge. The ability to treat *conforming* HTML5 as an 
> alternative infoset serialization is a pretty strong property. I 
> wouldn't give up on this property lightly. OK, there are a couple of 
> holes already, but they aren't yet too serious: form feed & vertical tab 
> (safely mapped to space) and non-NCName attributes on <embed> (don't 
> occur with real plug-ins).
> 
> If we conclude that adding namespacing that puts elements in a namespace 
> other than http://www.w3.org/1999/xhtml in the browser DOM when parsing 
> text/html is unworkable considering compat and if we still want a de 
> jure extension convention in HTML5, shouldn't we pick a prefix delimiter 
> that isn't special in XML and in IE but is still in ASCII, allowed in 
> NCNames and not used in existing HTML elements or attributes? (That 
> character would be the underscore.)

Consider the following XHTML fragment:

<a:b xmlns:a='urn'/>

This produces a DOM element with the following characteristics:

   name = 'a:b'
   localName = 'b'

Questions:

1) What would the proposed HTML5 serialization for this DOM be?

2) What DOM would be produced by the HTML5 parser for the serialization 
produced by #1?  Would it differ in a way that affects scripts, CSS, or 
the like?

3) Does IE support the W3C 'localName' property?

I'm not convinced that there is a problem here.

- Sam Ruby

Received on Monday, 6 August 2007 12:14:41 UTC