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

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

Received on Wednesday, 23 September 2009 04:21:39 UTC