xml-dev - Re: XML Schemas: Best Practices

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

Hi Folks,

Last week I asked for people to help me understand the limitations of
using the Chameleon Namespace design approach.  Recall that with this
design approach you create schemas with no namespace so that those
Chameleon components can incorporate into many different namespaces.
Toivo, Ron, and Curt came up with two limitations of this design
approach: (I will discuss the first limitation in this message.  The
second limitation will be discussed in a follow-up message.)

a. Name collision.  When you use Chameleon components those components
become part of the namespace, just as though you had typed the element
declarations and type definitions inline. If you <include> multiple
no-namespace schemas then there is an increasing risk of namespace
collisions. In fact, you may end up not being able to use some of the
no-namespace schemas because their use results in name collisions with
other Chameleon components.  To see this, consider this example:

Example.  Suppose that there are two schemas which create Chameleon
components:

1.xsd
   A
   B

2.xsd
  A
  C

Schema 1 creates no-namespace elements A and B.  Schema 2 creates
no-namespace elements A, and C.  Now if schema 3 <include>s these two
schemas there will be a name collision:

3.xsd
targetNamespace="http://www.example.org"
<include schemaLocation="1.xsd"/>
<include schemaLocation="2.xsd"/>

This schema has a name collision - A is defined twice.

Namespaces provide a way to avoid such collisions.  Above, if instead
those components resided in different namespaces then 3.xsd could have
<import>ed them and there would be no name collisions. [You can have the
same element/type name if the element/type is in different namespaces.]

My response:

There is a very simple solution to the namespace collision problem:
<include> each schema containing Chameleon components into a separate
schema that has a namespace and then <import> those two schemas into the
main schema:

<!-- Put the 1.xsd Chameleon components into this namespace -->
1-new.xsd
targetNamespace="http://www.foo.org"
<include schemaLocation="1.xsd"/>

<!-- Put the 2.xsd Chameleon components into a different namespace -->
2-new.xsd
targetNamespace="http://www.bar.org"
<include schemaLocation="2.xsd"/>

<!-- Import the components, which are now in namespaces -->
main.xsd
targetNamespace="http://www.main.org"
<import namespace="http://www.foo.org"
        schemaLocation="1-new.xsd"/>
<import namespace="http://www.bar.org"
        schemaLocation="2-new.xsd"/>

With this approach we avoid name collisions.  We also get the ability to
customize the components with <redefine>.

Contrast the above two-step process with this one-step process where we
put the components in a namespace from the very beginning:

1-fixed.xsd
targetNamespace="http://www.foo.org"
   A
   B

2-fixed.xsd
targetNamespace="http://www.boo.org"
  A
  C

main.xsd
targetNamespace="http://www.main.org"
<import namespace="http://www.foo.org"
        schemaLocation="1-fixed.xsd"/>
<import namespace="http://www.bar.org"
        schemaLocation="2-fixed.xsd"/>

This achieves the same result as the above two-step version.  In this
example, the components are not Chameleon.  Instead, A, B, and C were
placed into a namespace from the very beginning of their life.  If
main.xsd wants to <redefine> any of the elements it cannot.  It must
either take it or leave it.

I like the Chameleon approach even more!  Rather than starting a
component's life out in a rigid, static, fixed namespace, the Chameleon
approach frees them so that applications can decide on a domain
(namespace) for the components. Furthermore, applications can
refine/customize the Chameleon components.  This approach requires an
extra step but in return it gives you a lot of flexibility.  Wow! 

What are your thoughts on this?  /Roger