Henri Sivonen wrote:
...
Although this looks like a non-problem in browsers because the
Namespace-unaware DOM Level 1 view is available, it is a technical
problem with APIs that only provide a Namespace-aware representation.
For example, XOM doesn't allow attributes called xmlns:foo in the data
model. Non-browser consumers are important, and it should be perfectly
reasonable to use XOM in such a consumer.
...
Could you elaborate what exactly the problem with XOM is? I didn't get
it from this paragraph.
There's also a technical issue for browsers: For resolving a prefix in a
namespace mapping context on the XML side in a browser, it would make
sense to intern the prefix being queried and then do pointer compares
against interned local names of attributes in the
"http://www.w3.org/2000/xmlns/"; namespace as traversing up the tree. If
you ever wanted browsers to implement any RDFa features natively, being
sensitive to xmlns:foo attributes set with setAttribute() would preclude
a pointer compare-based lookup and would require actually inspecting
string data unless the internal data structures of browsers were
changed. (But see point #13 in my previous email on the topic of
changing the data structures.)
That doesn't seem to be true. An implementation of setAttribute (L1)
would just need to know that an attribute named "xmlns:*" is something
special, and internally map it.
...
Let's see if it's robust when a script mutates a parser-inserted attribute:
http://hsivonen.iki.fi/test/moz/xmlns-dom-setter-cc.xhtml
Not robust in Opera.
...
"A bug in Opera"?
...
BR, Julian
