Re: FPWD Review Request: HTML+RDFa

On Sep 3, 2009, at 18:09, Shane McCarron wrote:

> Henri Sivonen wrote:
>> On Sep 3, 2009, at 15:06, Anne van Kesteren wrote:
>>
>>> Treating xmlns as any other attribute seems like a violation of  
>>> the architecture of Namespaces in XML to me. I.e. a layering  
>>> violation.
>>
>>
>> Indeed, namespace declarations in XML don't appear in the  
>> [attributes] property of an element information item in the  
>> Infoset. They appear in the [namespace attributes] property and  
>> also affect the [in-scope namespaces] property.
>>
>> See http://www.w3.org/TR/xml-infoset/#infoitem.element
>>
>> It's highly unusual at the W3C to layer a spec (other than  
>> Namespaces itself of course) directly on top of XML 1.0 instead of  
>> layering it on top of XML + Namespaces (or the Infoset).
>>
> Well...  The specification under review doesn't say ANYTHING about  
> layering.

Are you implying that it's a good thing?

On Sep 3, 2009, at 18:43, Shane McCarron wrote:

> Anne van Kesteren wrote:
>> I don't think so as it would violate one of the more important  
>> design principles the HTML WG has, namely that of DOM consistency.
>
> Okay - I have a stupid question.  Right now, today, in HTML5, it is  
> possible for me to declare the 'mathml' and 'svg' namespaces, right?

The assignment of elements to the http://www.w3.org/2000/svg and http://www.w3.org/1998/Math/MathML 
  namespaces is not based on declarations.

> If that is the case, how are those attribute declarations manifested  
> in the HTML5 DOM?

When there are no declarations, there aren't any declarations  
manifested. However, the namespaceURI property is http://www.w3.org/1999/xhtml 
, http://www.w3.org/2000/svg or http://www.w3.org/1998/Math/MathML  
depending on whether the element is an HTML element, an SVG element or  
a MathML element.

If you put an attribute that in the source reads xmlns="http://www.w3.org/2000/svg 
" on an SVG element, it is manifested in the DOM as if it were a  
declaration of the default namespace. However, this attribute isn't  
what actually causes the parser to assign any element to a namespace.  
xmlns="http://www.w3.org/1998/Math/MathML" is treated analogously.

xmlns="http://www.w3.org/1999/xhtml" is NOT treated analogously. It  
isn't manifested in the DOM as if it were a namespace declaration. It  
is manifested as an attribute in no namespace with "xmlns" as the  
local name.

> In the XHTML5 DOM?

The XHTML5 DOM exactly an XML DOM for the purposes of the namespaceURI  
and localName DOM properties.

> Do these achieve "DOM consistency" ?

To the extent the namespaceURI and localName properties of conforming  
and meaningful elements and of conforming and meaningful attributes in  
the source go, yes. (The attribute with the local name "xml:lang" in  
no namespace doesn't count as meaningful and xmlns talismans don't  
count as meaningful for the purposes of the previous sentence.) To the  
extent attributes/namespace declaration that are spelled "xmlns" in  
the source go, no. However, the latter is harmless in the absence of  
the qnames-in-content/CURIEs pattern, because after parsing the  
application doesn't need to inspect namespace declaration but only the  
immutable namespaceURI properties of the nodes.

> And if so... can't we just extend that model so that  
> 'xmlns:ANYTHING' follows the same rules?  What am I missing here?


Not without code complexity and a backwards-compat risk.

What you are missing here is that the HTML5 parsing algorithm hard- 
wires 7 namespace URIs (null, "http://www.w3.org/1999/xhtml", "http://www.w3.org/2000/svg 
", "http://www.w3.org/1998/Math/MathML", "http://www.w3.org/XML/1998/namespace 
", "http://www.w3org/1999/xlink" and "http://www.w3.org/2000/xmlns/")  
but the xmlns:ANYTHING mechanism that RDFa calls for uses an open- 
ended set of URIs and prefixes.

The hard-wiring can be done with pointers or integers or enums  
interned even ahead of compile time, and the HTML5 parsing algorithm  
never requires the parser to examine the contents of an attribute name  
string beyond comparing it for equality. xmlns:ANYTHING is a different  
beast in terms of code complexity, since you go look at the contents  
of the string and split on colon.

You are also missing that if browser vendors take a compatibility risk  
(or a ship date slippage risk) with SVG-in-text/html parsing, they  
take a risk that enables them to get more value out of their  
*existing* SVG implementations but there's no such upside of getting  
more value out of existing code for taking a risk for RDFa.

For a longer treatment, please refer to:
http://lists.w3.org/Archives/Public/public-html/2009Mar/0163.html

On Sep 3, 2009, at 20:32, Mark Birbeck wrote:

> I was trying to explain why RDFa cannot be regarded as being "layered"
> on top of XML namespaces, because it doesn't actually require XML
> namespaces.
>
> RDFa only requires a prefix mapping mechanism, and this could just as
> easily have been @xmlns-dc, @banana:dc, @samruby="dc=..." or something
> else entirely.


I think the line of reasoning that you could have used something other  
than xmlns:prefix isn't convincing as a way to make xmlns:prefix OK.  
Or are you implying that xmlns:prefix can be removed from RDFa and  
replaced with something else for both HTML and XHTML, because  
xmlns:prefix isn't an essential characteristic of RDFa?

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

Received on Friday, 4 September 2009 06:44:17 UTC