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: sh...@aptest.com
