- From: Maciej Stachowiak <mjs@apple.com>
- Date: Thu, 01 Oct 2009 15:06:43 -0700
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Anne van Kesteren <annevk@opera.com>, Jonas Sicking <jonas@sicking.cc>, Adrian Bateman <adrianba@microsoft.com>, HTML WG <public-html@w3.org>, Tony Ross <tross@microsoft.com>, Sam Ruby <rubys@intertwingly.net>
On Oct 1, 2009, at 2:46 PM, Julian Reschke wrote:
> Maciej Stachowiak wrote:
>>> I'm referring to the algorithm that ways mentioned multiple times
>>> in RDFa threads: visit all parents, and check for all attributes
>>> where the local name is "xmlns", or starts with "xmlns:". Figure
>>> out namespace declarations from those.
>> That algorithm is incorrect. Prefix bindings apply at parse time,
>> not lookup time.
>
> Really? Pointer, please?
>
> Personally, I really don't care. I'm interested in processing
> content as sent over the wire (you know, documents, not web
> applications), where scripts never execute.
I don't think it's acceptable to design solutions that don't work for
scripting UAs, or for client-side JavaScript code that runs inside a
scripting UA.
>> Here's a test case, using XML. What's the namespace of the <bar>
>> element?
>> <foo xmlns:bar="http://example.com/bar">
>> <baz id="baz" />
>> <xhtml:script xmlns:xhtml="http://www.w3.org/1999/xhtml/">
>> var newElement = document.createElement("bar:bar", "http://barbar.com/barbar/
>> ");
>> document.getElemebtById("baz").appendChild(newElement);
>> </xhtml:script>
>> </foo>
>
> It depends on which API you use.
>
> I'll be happy to answer this for a *document*, not a DOM tree after
> script execution.
So there's no way to determine the identify of an element using only
DOM level 1 APIs in a UA that allows scripting.
>
>> Your algorithm says "http://example.com/bar" but the correct answer
>> is "http://barbar.com/barbar/". This is not just "an edge case" -
>> it will apply any time the DOM has been mutated after parsing. It
>> affects not just element or attribute creation, but also moving
>> chunks of the DOM from one place to another with different
>> namespace declarations in scope (the namespace URIs shouldn't
>> change for the moved content!) or to adding or removing namespace
>> declaration attributes.
>
> Yes, that's a problem when you're stuck with a non-namespace aware
> API.
It's a problem with claiming that non-namepsace aware APIs are the
solution to XML/HTML behavior differences.
> The best way to fix this is to make sure that UAs all implement
> namespace-aware APIs, and that they behave the same for XML and HTML
> content. I believe that's something this WG should do, instead of
> claiming that compatibility with broken web content prevents us from
> doing that.
I believe many of us have been consistent in rejecting DOM Level 1
APIs as a solution. It is the RDFa TF that has advocated use of non-
namespace-ware APIs as a way to ignore the differences in HTML and
XHTML parsing. It works for CURIEs because RDFa can define the time of
binding, but it is completely broken for determining the namespace of
an element or attribute.
>> Thus, your algorithm for finding the namespace URI of an element
>> using DOM Level 1 APIs may be well-defined but it is incorrect.
>
> See above.
I stand by my statement.
Regards,
Maciej
Received on Thursday, 1 October 2009 22:07:17 UTC