[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

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
namespace? 

I have summarized the discussion online:

http://www.xfront.com/ZeroOneOrManyNamespaces.html

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"
        elementFormDefault="unqualified"
        xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
        xsi:schemaLocation=
                      "http://www.w3.org/2000/10/XMLSchema
                       http://www.w3.org/2000/10/XMLSchema.xsd">
    <xsd:complexType name="Product">
        <xsd:sequence>
           <xsd:element name="Type" type="ProductType" 
                        minOccurs="1" maxOccurs="1"/>
        </xsd:sequence>
    </xsd:complexType>
    <xsd:simpleType name="ProductType">
        <xsd:restriction xsd:base="xsd:string">
           <enumeration xsd:value="Widget"/>
           <enumeration xsd:value="Gadget"/>
        </xsd:restriction>
    </xsd:complexType>
</xsd:schema>

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

• References:
  • Re: XML Schemas: Best Practices
    • From: "Roger L. Costello" <costello@m...>

• Prev by Date: RE: XML for Online Games
• Next by Date: RE: tabs to indent for pretty-printing (is it correct?)
• Previous by thread: Re: XML Schemas: Best Practices
• Next by thread: RE: XML Schemas: Best Practices
• Index(es):
  • Date
  • Thread