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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   nested namespaces

[ Lists Home | Date Index | Thread Index ]

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




 

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

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