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

On Mon, Sep 21, 2009 at 3:17 PM, Shane McCarron <shane@aptest.com> wrote:
> 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

But neither the HTML5 specification, nor Manu's draft, define a prefix
mapping algorithm for HTML documents. As far as I can see. I certainly
agree that one of those two needs to be the defining specification.

>> 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.

I certainly agree that it's pathological, but I do still think it
needs to be defined as when someone implements this they need to do
*something*.

However the more important question was if attributes in the null
namespace can have any affect on RDFa processing. You seem to indicate
that being the case. I'm curious if you're basing that on a
specification, or if that's just how you think things *should* be
defined?

/ Jonas

Received on Monday, 21 September 2009 22:24:01 UTC