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


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] nested namespaces

[ 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" 

<xsl:template match="//*[namespace-uri()='http://example.com/b']">
 <xsl:value-of select="name()" /> <xsl:apply-templates />

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 
	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:
	   <b:rule test="">
	   <d:rule test="">
	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
	For example:
	     <a:leaf />
	       <a:leaf />
	     <a:leaf />
	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>


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS