- From: Bjoern Hoehrmann <derhoermi@gmx.net>
- Date: Wed, 10 Oct 2007 22:48:14 +0200
- To: Henri Sivonen <hsivonen@iki.fi>
- Cc: www-svg <www-svg@w3.org>, public-cdf@w3.org
* Henri Sivonen wrote: >DOM doesn't capture the namespace mapping scope at the node creation >time. It doesn't even provide API-native convenience methods for >resolving qNames-in-content into NS,localName pairs. Even if you >bother to walk the tree using code you wrote yourself because DOM >didn't do it for you, the meaning of qNames is brittle when nodes are >moved around. When you walk towards the root you may find very >different ns declarations if the node you start from has been moved >to another subtree after the initial DOM build. I have a hard time following your criticism. It is true that the DOM is unaware of possible dependencies between some content and its context, and moving nodes without reconstructing the context may have undesirable or unexpected effects. This is true for most inherited declarations and relative references (the language of the node may change due to xml:lang attributes, resource identifiers may change due to xml:base attributes, event handlers may behave differently because the node's parent changed, "QNames" may resolve to different names due to xmlns attributes, etc.) That's a rather general problem, and beyond that, I am not sure what you are saying. The DOM retains namespace declarations, you can query and update them and you can easily look up the namespace name for a prefix or the prefix for a namespace name; you might have missed .lookupPrefix, .isDefaultNamespace, and .lookupNamespaceURI, otherwise I don't see why you would walk the tree yourself. Making yet more convenient methods would be difficult due to differences in "QName" semantics and limitations in the usual programming languages; for example, XML Schema maps unprefixed names to the declared default namespace, Atom link relations map them to http://www.iana.org/... and XSLT maps them to no namespace at all, and neither Java nor ECMAScript support tuples as return value unless you wrap them inside something -- and then it'd be difficult to see how that's better than using split(). Could you perhaps rephrase what problems you see here, other than the first I've mentioned above? -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Received on Wednesday, 10 October 2007 20:48:14 UTC