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] More on namespaces...

[ Lists Home | Date Index | Thread Index ]

On Monday, June 9, 2003, at 08:21 AM, Seairth Jacobs wrote:

> The whole xmlns thread has left me more confused about what should and
> should not be done with namespaces...  so, can someone answer these
> questions:
>
>
> 1) Suppose you have a vocabulary that states that only <B> may be 
> within
> <A>.  Now suppose you have another vocabulary with element <C>.  If 
> one were
> to do <ns1:A><ns1:B/><ns2:C/></ns1:A>, would the document still be 
> valid
> according to the first vocabulary?

That depends on how the schema for ns1 was defined::

   <xs:import namespace="...ns2..." />
   <xs:element name="A">
     <xs:complexType>
       <xs:sequence>
         <xs:element ref="ns1:B" />
         <xs:element ref="ns2:C" />
       </xs:sequence>
     </xs:complexType>
   </xs:element>

This probably isn't the type of vocabulary mixing that you were 
thinking of, though, since the ns1 schema is aware of and requires the 
ns2 schema. The document author has no choice but to use elements from 
both vocabularies.

To allow document authors to extend an existing vocabulary and still be 
valid, you would need to use wildcards::

   <xs:element name="A">
     <xs:complexType>
       <xs:sequence>
         <xs:element ref="ns1:B" />
         <xs:any namespace="##other" />
       </xs:sequence>
     </xs:complexType>
   </xs:element>

This gives the document author the ability to add (just one) element 
from any namespace while still remaining valid. Presumably, 
applications that can process ns1 documents will silently skip any ns2 
elements. What strikes me as odd is that it takes extra work on the 
part of the schema authors to allow for this type of extensibility.

There are other ways to combine vocabularies that aren't so benign::

   <ns1:A><ns2:C><ns1:B /></ns2:C></ns1:A>

Should a document author be allowed to do the above? Both DTDs and XML 
Schemas are incapable of handling this type of extensibility. From what 
I've been able to digest from Arjun's posts, it seems that 
architectural forms would allow for ns1-aware applications to both 
correctly validate and process the above document.

> 4) Should a vocabulary be able to dictate how other vocabularies can 
> be used
> with it?  I am talking about the general case where the specifics of a
> secondary vocabulary are not known.  For instance, can a vocabulary 
> state
> that absolutely no elements, regardless of where they come from, may be
> within element <x>?  Another way of looking at this question is:  
> should a
> vocabulary explicitly state what is allowed for secondary 
> vocabularies?  If
> vocabulary does not define this, what should the "default" behaviour 
> be?

The default behavior for all of the major XML schema languages (with 
the notable exception of Schematron) disallows elements from other 
vocabularies from appearing in documents conforming to the described 
vocabulary. As shown above, this requires extra work to get right and 
isn't even possible for all cases. In some schema languages (like 
DTDs), it's not even possible to extend a vocabulary without creating a 
new DTD (and hoping the original DTD made good use of parameter 
entities).

I think that the point that Arjun has been trying to make is that each 
document is really defining it's own vocabulary (or has the potential 
to). Translating the elements and attributes from your (the document 
author's) vocabulary to my (an application specific) vocabulary and 
omitting the elements and attributes from your vocabulary that have no 
place in my vocabulary is a simple matter of looking past the names of 
the elements and attributes as they happen to be serialized in your 
document and mapping them to the names my application understands.

-- 
Jason Diamond
http://injektilo.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