On 9/22/09 11:36 PM, Shane McCarron wrote:
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
I should note that I'm assuming the method Jonas meant is
lookupNamespaceURI; if there is any reason to consider this assumption
suspect please let me know.
The issue under discussion is that of HTML input syntax, no? For what
it's worth, I believe that this method as specified in the DOM 3 Core
specification is not likely to produce anything worthwhile if parsing as
currently proposed in the HTML5 specification (or as de-facto
implemented for HTML4 documents).
But even if we restrict to XML and consider practical application of
this approach when operating on a DOM there are issues here involving
the exact ordering of this call and modifications to the DOM which
involve removing or adding xmlns attributes. Most simply, it is quite
easy to produce a DOM Element in namespace "bar" and with prefix "foo"
that has an attribute with prefix "xmlns", namespace URI
"http://www.w3.org/2000/xmlns/";, localname "foo", and value "notbar"
using DOM manipulation. Note for future reference that in such a
situation lookupNamespaceURI("foo") on any descendant of the node in
question will return "bar".
Example of a DOM Element as above:
<foo:x xmlns:foo="bar"/>
in the markup, followed by execution of the following DOM Core method
calls, where |myElement| is the element in question:
myElement.removeAttributeNS("http://www.w3.org/2000/xmlns/";, "foo");
myElement.setAttributeNS("http://www.w3.org/2000/xmlns/";, "xmlns:foo",
"notbar");
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.
Not at all; see example above in which this algorithm would return
"notbar" while algorithm number 1 returns "bar".
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.
Not at all. Most simply, in this HTML4 document:
<html xmlns:foo="bar">
and using the de-facto DOM representation of HTML4 this algorithm will
produce "bar" while algorithms 1 and 2 will produce nothing at all.
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.
OK.
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.
Which ones? They gave three different answers.... This will by
definition give the same answer as 2 in XML documents and as 3 in HTML
documents, of course.
Well... yes. for example, you could follow the algorithm as defined in
the RDFa Syntax Recommendation.
I assume we're talking about
<http://www.w3.org/TR/2008/REC-rdfa-syntax-20081014>, right? If not,
can you please point me to the right document?
Assuming we are....
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.
Maybe I'm missing something. The relevant part of the above document
seems to be at <http://www.w3.org/TR/rdfa-syntax/#T_URI_mapping>, right?
It says:
Next the [current element] is parsed for [URI mapping]s and these
are added to the [local list of URI mappings].
I'm not sure what it means to "parse" a DOM Element, but let's keep
going in hopes of it being defined. The document then says:
Mappings are provided by @xmlns. The value to be mapped is set
by the XML namespace prefix, and the value to map is the value
of the attribute—a URI. Note that the URI is not processed in
any way; in particular if it is a relative path it is not
resolved against the current [base]. Authors are advised to
follow best practice for using namespaces, which includes not
using relative paths.
I'm not sure what "@xmlns" means here. An attribute with localName
"xmlns"? Something else? What does "the XML namespace prefix" mean
here? The prefix for a prefix:localName value in XML Namespaces terms?
Something else? Either there's a lot of context I'm missing (and
would love to be directed toward) or this
In any case, this does make it clear that only attributes are considered
for defining prefix mappings, thus eliminating Jonas' proposed algorithm
#1 if using a DOM model when looking for mappings.
I should note that the "up vs down thing" you mention above seems like a
red herring to me; as the document explicitly says,
Note that a [URI mapping] will simply overwrite any current
mapping in the list that has the same name;
There is no difference between going down the tree while applying the
above rule and going up the tree and stopping at the first place that
defines a mapping for a given name. They have equivalent behavior.
The real question Jonas asked is what defines a mapping, period. It
doesn't seem to be particularly well-defined in the above text. I hope
I'm looking at the wrong document...
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.
See counterexamples above, in the specific "operating on a DOM produced
by an XML or HTML parser" environment. Usually the next step in such a
situation (a proof of statement X exists and then counterexamples to
statement X are produced) is looking for errors in the proof or in the
construction of the counterexamples. I'd love to see any errors I made
pointed out. Is the issue the definition of "supported" in your claim?
Respectfully,
Boris
