[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XML Schemas: Best Practices

  • From: "Roger L. Costello" <costello@m...>
  • To: xml-dev@l...
  • Date: Mon, 06 Nov 2000 15:37:26 -0500

xsd targetnamespace
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


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.