Re: Namespace: what's the correct usage?

[Martin Gudgin <marting@develop.com>]

----- Original Message -----
From: "Jeni Tennison" <mail@jenitennison.com>
To: "Martin Gudgin" <marting@develop.com>
Cc: <xml-dev@lists.xml.org>
Sent: Sunday, May 20, 2001 8:45 AM
Subject: Re: Namespace: what's the correct usage?



> I come from a processing-using-XSLT perspective. There, of course,
> it's fairly easy to check the name of the parent element and do things
> differently accordingly:
>
> <xsl:template match="p:book/p:title">...</xsl:template>
> <xsl:template match="p:author/p:title">...</xsl:template>
>
> The real problem is where you have mixed namespaces:
>
> <p:book xmlns:p='urn:x1'>
>   <p:title>The Hobbit</p:title>
>   <p:genre>Fantasy</p:genre>
>   <a:author xmlns:a="urn:x2">
>     <a:title>Dr</a:title>
>     <a:familyName>Tolkien</a:familyName>
>   </a:author>
> </p:book>
>
> With qualified elements, I can easily distinguish between the two
> titles:
>
> <xsl:template match="p:title">...</xsl:template>
> <xsl:template match="a:title">...</xsl:template>
>
> With local scoping, I always have to check the parent, as all the
> title elements are in the same (null) namespace:
>
> <xsl:template match="p:book/title">...</xsl:template>
> <xsl:template match="a:author/title">...</xsl:template>
>
> Perhaps that's not so bad here, where you only have to look up one
> level, but it becomes very difficult if you have documents that use
> the null namespace throughout. Working out what namespace these
> elements are 'inheriting' - what vocabulary they come from involves
> looking at the nearest qualified ancestor and get its namespace URI:
>
>   namespace-uri(ancestor::*[namespace-uri()][1]) = 'xxxx'
>
> That's really laborious - a whole lot more laborious than using a
> prefix in an XPath to select or match only elements in a particular
> namespace.

I think that this is a valid argument. When processing is not-sequential (
i.e. you may not have 'seen' the qualified parent ) then with local scoping
you have to do more checking. Thanks for bringing this up, I was thinking
mainly about SAX ContentHandler or DOM based depth-first traversal. I'll
spend some time thinking about the XSLT scenario.

>
> > And I think the shortcut has already been taken. If anything, this
> > makes it safer by not fooling people into thinking they know how to
> > process an element based entirely on its local name and namespace
> > name.
>
> But *taking away* one of the basic scraps of information that they
> have about how to process an element doesn't exactly help, does it?
> "It's difficult, so we'll make it more difficult so you don't get
> fooled into thinking it's easy." The namespace of an element is a
> piece of contextual information that usually makes a lot of difference
> to how it's processed - why make that piece of context harder to get
> at?

I don't think it makes that much difference. If local scoping is going on
then whether the children are qualified or not doesn't make that much
difference. In the XML Schema transfer syntax all the elements are
qualified. If I want to write an XSLT to process a schema document I may
need to deal with the fact the several elements ( restriction, for example )
mean different things in different contexts, so I'll need to write XPaths
along the lines of a:simpleType/a:restriction or
a:complexContent/a:restriction anyway. Of course, many may consider this a
contrived example seen as it is the schema language itself ;-)

>
> Having locally scoped namespaces is absolutely fine if you're not
> mixing namespaces, because you can just look to the root element and
> see what namespace it has. But when you have mixed namespaces, local
> scoping can make life a lot more complicated. Or at least that's the
> case with current XPaths - perhaps XML Schema support in XPath 2.0
> will add something to help.

Yeah, having XPath be type based rather than name based will be fantastic.
The MSXML4 parser[1] from Microsoft has some ( proprietary ) support for
that today. I can't wait for that stuff to be standardised and avaibable in
all processors.

Cheers

Gudge

[1] http://msdn.microsoft.com/xml/general/newinaprilre.asp