Re: @rel syntax in RDFa (relevant to ISSUE-60 discussion), was: Using XMLNS in link/@rel

On Feb 27, 2009, at 14:57, Henri Sivonen wrote:

> Going back to the design of exposing text/html as if it were XML: As  
> I pointed out earlier, xmlns:foo in text/html parses, in existing  
> browsers and in the HTML5 parsing algorithm as drafted today, into a  
> [namespace, local] pair where the local part is not an NCName. This  
> characteristic alone (i.e. without even considering the part that is  
> spelled "xmlns") is enough to render the [namespace, local] pair  
> unrepresentable in XML 1.0 + Namespaces.
>
> This poses the following problems:
> 1) A local name that is not an NCName cannot be serialized as XML  
> 1.0 in such a way that parsing the resulting XML document with a  
> namespace-aware parser round-trips the non-NCName local name properly.
> 2) Namespace-wise strictly correct XML tree implementations throw if  
> you try to set an attribute that can't be serialized as XML 1.0 +  
> Namespaces. (A demo that makes XOM throw is included below my  
> signature.)
> 3) Even if the API contract of an XML API could be violated and a  
> local name that is impossible in XML 1.0 + Namespaces could be  
> passed through, this representation would be *different* from the  
> way an XML parser would expose an attribute spelled "xmlns:foo"  
> though the same API. Thus, the application-layer code would have to  
> differ for text/html and application/xhtml+xml.


Oops, I forgot to add:

For these reasons, considering that the vocabulary that HTML5 defines  
as conforming and meaningful (i.e. excluding xml:lang in text/html  
which isn't meaningful) uses only NCNames, HTML5 defines a coercion  
onto Infoset that doesn't preserve non-NCName element or attribute  
names. Non-browser HTML parsers that expose an XML API may use this  
coercion. Absent RDFa, this isn't a problem.

http://www.w3.org/TR/html5/tree-construction.html#coercing-an-html-dom-into-an-infoset

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Friday, 27 February 2009 13:09:59 UTC