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

Re: Request to publish HTML+RDFa (draft 3) as FPWD

From: Shane McCarron <shane@aptest.com>
Date: Mon, 21 Sep 2009 17:17:02 -0500
Message-ID: <4AB7FB5E.8040102@aptest.com>
To: Jonas Sicking <jonas@sicking.cc>
CC: Maciej Stachowiak <mjs@apple.com>, Manu Sporny <msporny@digitalbazaar.com>, HTMLWG WG <public-html@w3.org>, RDFa mailing list <public-rdf-in-xhtml-tf@w3.org>
Jonas,

Let me tackle your specific technical questions.  I tried to address 
some higher level issues in a separate message to Maciej.

Jonas Sicking wrote:
> As I have pointed out, the "Namespaces in XML" recommendation [1] only
> defines processing for XML documents. Which is not what we have here.
> We have an HTML document or a DOM. The HTML specification defines a
> mapping from a HTML document to a DOM, so specifying processing for a
> DOM would be enough for defining processing for a HTML document as
> well.
>
> Put it another way. Can you point to the language that specifies how
> the following HTML document should be processed:
>
> <!DOCTYPE html>
> <html>
> <head><title>HTML+RDFa example</title></head>
> <body>
> <table xmlns:cc="http://creativecommons.org/ns#">
> <a rel="cc:license"
>   href="http://creativecommons.org/licenses/by-nc-nd/3.0/">
>   Creative Commons License
> </a>
> <tr><td>Example table</td></tr>
> </table>
> </body>
> </html>
>
> Note that in the resulting document, when parsed as HTML, the <table>
> element is not a parent of the <a> element. 

Sure.  The rules for processing a source document are defined in the 
context of the host language. In this case, the HTML 5 specification 
indicates the rules for munging the input (I suppose).  RDFa doesn't 
care what the host language does with valid input (I am assuming the 
above is valid HTML5).  See the normative section 2 and informative 
seciton 2.1 of Manu's draft at 
http://html5.digitalbazaar.com/specs/rdfa.html

> Similarly, in the
> following document:
>
> <!DOCTYPE html>
> <html><head>
> <script>
> onload = function() {
>   document.body.setAttribute("xmlns:cc", "http://creativecommons.org/ns#");
>   document.body.setAttributeNS("http://www.w3.org/2000/xmlns/",
> "xmlns:cc", "http://mynamespace.example.com/#");
> }
> </script>
> <title>Second RDFa+HTML example</title>
> </head>
> <body>
> <p>
> <a rel="cc:license"
>   href="http://creativecommons.org/licenses/by-nc-nd/3.0/">
>   Creative Commons License
> </a>
> </p>
> </body>
> </html>
>
> Note, in the resulting document, after the "load" event has finished
> firing, there are two different attributes with the tagName "xmlns:cc"
> on the body element.
>   

Interesting issue.  I do not think this (to me, pathological) case is 
defined.  Processing after mutation events such as this is clearly 
something that would only happen in browser environments, but 
regardless...  The DOM2 and DOM3 Recommendations indicate that mixing NS 
and non-NS methods on the same DOM is a bad idea, and that the behavior 
is unpredictable.  So my first reaction is "don't do that". 

If you are requesting that we address this case specifically, I would be 
open to dealing with it in the context of an errata to the RDFa Syntax 
specification.  Probably this would be in conjunction with my proposed 
errata to section 5.5 step 2. In general, I would say that when there 
are attributes in the null namespace and attributes in the xmlns 
namespace on the same element that would have had have the same lexical 
declaration, the  item in the xmlns namespace must take precedence.  
However, as I said above, I feel this case is pathological. 

> If you do think processing is defined for both these cases, can you
> please point to exactly where. I.e. which paragraph or paragraphs in
> which specs.
>
> [1] http://www.w3.org/TR/xml-names/
>
> / Jonas
>   

-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com
Received on Monday, 21 September 2009 22:17:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:48 GMT