OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Namespace: what's the correct usage?

Hi Martin,

> So what would you do with the following XML document?
> <p:book xmlns:p='urn:x1'>
>   <p:title>The Hobbit</p:title>
>   <p:genre>Fantasy</p:genre>
>   <p:author>
>     <p:title>Dr</p:title>
>     <p:familyName>Tolkien</p:familyName>
>   </p:author>
> </p:book>
> All the elements are namespace qualified. How do you distinguish
> between the two title elements?

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>
  <a:author xmlns:a="urn:x2">

With qualified elements, I can easily distinguish between the two

<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

> 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

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.



Jeni Tennison