[
Lists Home |
Date Index |
Thread Index
]
I'm sorry but I can't see what problem it is you are stating. If I was processing your latter XML document and needed only elements from the "http://example.com/a"; namespace I'd write
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform";>
<xsl:template match="//*[namespace-uri()='http://example.com/b']">
<xsl:value-of select="name()" /> <xsl:apply-templates />
</xsl:template>
</xsl:stylesheet>
or
declare namespace a = "http://example.com/a";
let $i := document("container.xml")
return for $a in $i//a:*
return name($a)
substituting the call to name() with whatever processing code was needed.
-----Original Message-----
From: Simon St.Laurent [mailto:simonstl@simonstl.com]
Sent: Sun 12/15/2002 2:23 PM
To: xml-dev@lists.xml.org
Cc:
Subject: [xml-dev] nested namespaces
I'm working on a couple of projects which rely on multiple namespaces
mixed up in the same document as a matter of course. For example:
<a:container
xmlns:a="http://example.com/a";
xmlns:b="http://example.com/b";
xmlns:c="http://example.com/c";
xmlns:d="http://example.com/d";
xmlns:e="http://example.com/e";
>
<b:rule test="">
<c:result>value</c:result>
</b:rule>
<d:rule test="">
<e:result>value</c:result>
</d:rule>
</a:container>
The general notion is that when you encounter a namespace your processor
doesn't understand, you try its following sibling instead. If there is
no sibling, you go back up to your parent to see if it has any following
siblings to offer, etcetera, and if you land at the root element again,
you're out of luck.
I'm worried that this is a somewhat perverse case, though given the
nature of the project (an element-based approach to identifying
information in a wide variety of different kinds of resources and
situations), I don't see a lot of other options.
More generally, I'm wondering about cases where developers use container
elements in one namespace which may be different from either the
namespace of the parent element or the namespaces used by the child
elements.
For example:
<a:container
xmlns:a="http://example.com/a";
xmlns:b="http://example.com/b";
>
<b:container>
<a:leaf />
<a:branch>
<a:leaf />
</a:branch>
<a:leaf />
</b:container>
</a:container>
Some people seem to assume that elements in namespaces you don't
understand can be discarded, but what gets discarded here?
In most of my (naive) SAX parsers, I'd just ignore the b:container tags
if I didn't know what they meant, and proceed happily to the a:leaf and
a:branch tags. DOM processors might react differently, ignoring the
entire node, unless they knew somehow that they should dig more deeply.
I don't believe that there is a standard set of rules for this kind of
processing, and I worry that there are a lot of people who assume that
their understanding of what rules might apply is the understanding of
the rules.
This is an area that Namespaces in XML pretty plainly avoided, but it
may be an area that we need to consider more and more as we get deeper
into documents which mix and match namespaces on terms which aren't
always clearly defined in advance. (I haven't seen Microsoft request
that the W3C add the extra namespaces and elements it uses in the
old-style Office-generated HTML to the XHTML spec, for instance, though
perhaps they've written a module for it.)
Any thoughts? I don't see any obvious answers here.
--
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com -- http://monasticxml.org
-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>
The list archives are at http://lists.xml.org/archives/xml-dev/
To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>
|
