[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: Tue, 31 Oct 2000 12:56:00 -0500

enumeration xsd
Hi Folks,

Yesterday we began discussing the issue:

In a project where multiple schemas are created, should each schema
reside in a separate namespace, or should all the schemas reside within
a single, umbrella namespace, or should some of the schemas be in no

I have summarized the discussion online:


You will see that I have formalized the three designs (i.e., I have
given the designs a name):

[1] Heterogeneous Namespace Design: 
         create a different namespace for each schema  
[2] Homogeneous Namespace Design:
         create a single, umbrella namespace for all schemas
[3] Chameleon Namespace Design: 
         create a namespace for the "main" schema and no namespace 
         for the "supporting" schemas (the supporting schemas will
         take on the namespace of the main schema, just
         like a Chameleon)

Towards the bottom of the document I have started to list the tradeoffs
of the three designs.  Here's as far as I got:

Design Tradeoffs

Above we explored the "design space" for this issue. We looked at the
three design approaches "in action", both schemas and instance
documents. So which design is better? Under what circumstances?

The Chameleon design is the most flexible design and is the one that
should be used where possible. With this approach the "supporting
schemas" are infinitely malleable - they are able to take on the
namespace of any schema that <include>s them (the Chameleon effect).

However, there are serious limitations to this design approach, which
prohibits its use in many cases. To see this, let's modify Products.xsd
by creating a simpleType which enumerates the products:

Product.xsd (no targetNamespace, extended with simpleType)

<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2000/10/XMLSchema"
    <xsd:complexType name="Product">
           <xsd:element name="Type" type="ProductType" 
                        minOccurs="1" maxOccurs="1"/>
    <xsd:simpleType name="ProductType">
        <xsd:restriction xsd:base="xsd:string">
           <enumeration xsd:value="Widget"/>
           <enumeration xsd:value="Gadget"/>

Observe that the "Type" element is now of type "ProductType". When the
company schema <include>s this schema all the elements and types get
namespace-coerced into the company namespace. Product, Type, ProductType
all become members of the http://www.company.org namespace. See the
problem? The Type element is of type {}:ProductType, i.e., ProductType
in no namespace. But the only ProductType that now exists is the one in
the company namespace! So, this schema fails. 

In general, the Chameleon design only works when the supporting schemas
contain independent, decoupled components. Whenever you have such a
situation this is the design of choice.

Do you agree with this recommendation?  What are the pros/cons of the
two other designs? 

I need some help thinking this through.  What are your thoughts on the
pros/cons of the three design approaches?  /Roger


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.
First Name
Last Name
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.