xml-dev - Re: XML Schemas: Best Practices

["Roger L. Costello" <costello@mitre.org>]

Hi Folks,

I need your feedback on the schema design approach which I have been
calling the "Chameleon Namespace design".  Recall that with this design
approach you do not assign a targetNamespace to your schemas.  The
schema components are thus in "no-namespace".  When another schema
<include>s the no-namespace components, the components take on the
namespace of the schema doing the <include> (hence, the name
"Chameleon").

I am really excited about this design approach.  I see many benefits. 
It is such a novel and exciting design strategy.  

I fear, however, that in my exuberance I may have blinders on and may
not be seeing the disadvantages.  I need you to help open my eyes to any
downsides.  Below I have listed what I perceive to be the benefits of
this approach: 

- The components in the schemas with no targetNamespace (the
"no-namespace" components) are infinitely malleable - they are able to
take on the namespace of any schema that <include>s or <redefine>s them
(the Chameleon effect). 

- The no-namespace components can be reused by any schema. 

- The no-namespace components can assume many different semantics. For
each schema that <include>s them, they can take on a new role and new
semantics. 

- The no-namespace components can be <redefine>d by any schema,
regardless of the schema's targetNamespace. 

- The no-namespace components are not "fenced in" by a namespace. They
are free, independent, and with no boundaries. They owe their allegiance
to no namespace! 

Pretty powerful design, aye?  It enables a whole new breed of reusable
components.  As excited as I am about this design approach, I am also
struggling with it because it really strikes at the heart of namespaces,
and calls into question their value.  At minimum, it relegates 
namespaces to a lesser (or different) role.

What are your thoughts on this design approach?  /Roger