W3C home > Mailing lists > Public > www-svg@w3.org > November 2002

Re: [svg-developers] Re: some discussion of SVG 1.2

From: Robin Berjon <robin.berjon@expway.fr>
Date: Mon, 18 Nov 2002 18:42:06 +0100
Message-ID: <3DD9266E.7010007@expway.fr>
To: Jim Ley <jim@jibbering.com>
CC: www-svg@w3.org

Jim Ley wrote:
> "Robin Berjon" <robin.berjon@expway.fr>
>>Of course not. Presumably, prefixes in the XPath expressions would be
>>mapped to  namespaces based on the current namespace context, as
>>it is in XSLT.
> and if that namespace context changed?

Then the meaning of the enclosed XPath would change as well. This is the pandora 
box of QNames in content. However if other languages have survived it, why not SVG?

> My problem with using the
> prefix, is that the prefix is supposed to disappear once you've parsed
> the XML, which would mean your
> (//rect[@ex:type='stepBox']).mouseover
> would have to be expanded to:
> (//rect[@urn:moo:type='stepBox']).mouseover
> on parsing, which means why bother with the extra confusing layer - why
> not just work with the namespace direct?

Well we have the chance of having that information available, so why not use it? 
Your example seems fine because you use the "urn:moo" namespace, which is simple 
enough. Replace that with 
"http://xmlns.mycoolcompany.com/SVG/extension/rect/1.0/" and you get:


which is starting to be a little less readable, provided we forget the fact that 
that isn't XPath syntax at all. Not that making it comply with the XPath syntax 
is hard:

and local-name()="type"]='stepBox']).mouseover

(Not sure that's completely correct, but the general idea's there). 
Alternatively, we could use XPointer's xmlns() scheme, which would yield 
something along the lines of:


which isn't of paramount clarity either. If you picture any of the above with 
several uses of the namespace, only the last one doesn't double in size and 
unreadability with each occurence.

My reasoning is thus that if we have XPath we need namespaces, and if we need 
namespaces we might as well use the context we have: it's more readable and less 
error-prone. I'm not very fond of the QNameInContentKludge, but I must say that 
I haven't seen many nice alternatives.

Robin Berjon <robin.berjon@expway.fr>
Research Engineer, Expway
7FC0 6F5F D864 EFB8 08CE  8E74 58E6 D5DB 4889 2488
Received on Monday, 18 November 2002 12:42:31 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:46:54 UTC