W3C home > Mailing lists > Public > www-svg@w3.org > October 2007

Re: @role in SVG

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
Message-ID: <hkbqg3919dkhemig6qjiu1l3i9re3622if@hive.bjoern.hoehrmann.de>

* 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:23 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:37 GMT