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

Boris,

My comments below:

Boris Zbarsky wrote:
> On 9/22/09 5:17 PM, Shane McCarron wrote:
>>> I think I found the code that extracts prefix mappings, and it appears
>>> that it uses method 3. So my question is, why is this more correct
>>> than any of the other 4 methods i proposed?
>> It's not. Modulo the issue with collisions, which I have already
>> acknowledged as an edge case we should specify. It doesn't matter. Its
>> an implementation choice
>
> How can it possibly be an implementation choice which algorithm to use 
> if the options give different answers for prefix mappings?  Either 
> it's not an implementation choice, or the specification allows pretty 
> wide latitude of "conforming" behavior....  Which is it?
>
>> But I am convinced it would render the same prefix mappings.
>
> The 5 methods Jonas listed give 5 different sets of prefix mappings, 
> at first glance.
Okay.  I admit I didn't think super hard about it but here are the 
various methods Jonas proposed:

> 1. Call Node.lookupNamespacePrefix as defined by DOM Level 3 using
> "foo" as the prefix argument.

Awesome.  This method, if supported in the environment, would give you the correct local mapping.  Because in such an environment, you would have an accurate transformation of the XML input syntax into a DOM that supports that method and that knows the mappings.  As I said, awesome.

> 2. Walk up the parent chain looking for an element with an attribute
> with localName "foo" and namespace "http://www.w3.org/2000/xmlns/",
> and then use the value of that attribute.

If the implementation supports the transformation of namespace declarations to such nodes, then this will work and it will be just as awesome.  In such an implementation, you will find the same mapping that option 1 would return - by definition.

> 3. Walk up the parent chain looking for an element with an attribute
> with tagName "xmlns:foo", and then use the value of that attribute.

If the implementation supports the exposure of the lexical namespace declarations via the name property of an attribute node, then yes, this method will cough up the same declaration that option 2 and option 1 would cough up.

> 4. Walk up the parent chain looking for either the attribute in 2 or
> 3, and if both are specified use some prioritization order.

This is the interesting edge case we have discussed a few times now. In an implementation where option 1 or option 2 works AND option 3 works...  you might have this problem.  I agree that it would be reasonable to define the prioritization order.  Personally I think the proper prioritization is to prefer an item in the XMLNS namespace over one in the null namespace.

> 5. Walk up the parent chain looking for either the attribute in 2 if
> the document was parsed as XHTML, or attribute in 3 if the document
> was parsed as HTML.

This would be fine, and I maintain would render the same prefixes as the options above.

> 6. Do something else?

Well... yes.  for example, you could follow the algorithm as defined in 
the RDFa Syntax Recommendation.  As Mark mentioned earlier, that 
Recommendation defines a model where you never traverse UP the tree.  
You evaluate the current node to find any prefix mapping declarations 
and put them into context.  You then pass that context down the tree as 
you traverse it during processing.  You can do this using a SAX model, a 
XOM processor, a DOM model, a tokenizing parser.... it doesn't matter.

So, I still think that I was right.  You get the same triples in all 
these cases ASSUMING you are using a method that is supported by the 
environment in which your implementation is running.  Q.E.D.

-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com

Received on Wednesday, 23 September 2009 03:37:21 UTC