[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Namespace: what's the correct usage?

  • From: Martin Gudgin <marting@d...>
  • To: Jeni Tennison <mail@j...>
  • Date: Sun, 20 May 2001 12:20:38 +0100

correct usage of ms

----- Original Message -----
From: "Jeni Tennison" <mail@j...>
To: "Martin Gudgin" <marting@d...>
Cc: <xml-dev@l...>
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




PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.