OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: XML Schemas: Best Practices

[ Lists Home | Date Index | Thread Index ]
  • From: "Roger L. Costello" <costello@mitre.org>
  • To: xml-dev@lists.xml.org
  • Date: Mon, 06 Nov 2000 15:07:16 -0500

Hi Folks,

In a few moments I will send out a message that addresses the
limitations of Chameleon components that Toivo, Ron and Curt raised last
week. (I believe that I have some good answers.  I would be very
interested in your thoughts.)

Before that I would like to present an example that shows the use of
Chameleon components.  I sense some confusion about Chameleon
components.  I hope that this example will clear up the confusion.

Example.  For my example, I would like to continue with the example that
Toivo started last week:

<Toivo-Example>

Let's say you are looking for a new car and you want to query the
web for cars under $20,000 with a user rating of greater 4 out of 5.
Let's say my search engine found the following two code snippets:

<productinfo xmlns="http://www.products.com">
   <car>Honda Civic</car>
   <price>$16,000</price>
   ...
</productinfo>

<userreviewsummary xmlns="http://www.reviews.com">
   <productreviewed>
      <car>Honda Civic</car>
   </productreviewed>
   <rating max="5">4.7</rating>
   ...
</userreviewsummary>

Note that one "car" element is in the "http://www.product.com" namespace
and the other is in the "http://www.reviews.com" namespace.

</Toivo-Example>

In Toivo's example the <car> element is the Chameleon component.  It was
created in a schema with no targetNamespace (I will show the schema in a
moment).  In Toivo's example we see <car> being used within two
different namespaces, and in each case it is "taking on" the namespace
of the document that is using it.  That is, in the first case it is
taking on the namespace: http://www.product.com, and in the second case
it is taking on the namespace: http://www.reviews.com.

So we see that Chameleon components are very flexible - they are able to
incorporate into many namespaces.  

Here is the schema which creates the <car> element:

Car.xsd

<?xml version="1.0"?>
<schema xmlns="http://www.w3.org/2000/10/XMLSchema"
        elementFormDefault="qualified"
        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">
   <element name="car" type="string"/>
</schema>

Note that it has no targetNamespace.  Thus, <car> is a no-namespace
element.  It is a Chameleon element.  It can be used in any schema which
<include>s or <redefine>s this schema.  Here is the schema for the first
XML snippet above (productinfo):

ProductInfo.xsd

<?xml version="1.0"?>
<schema xmlns="http://www.w3.org/2000/10/XMLSchema"
        targetNamespace="http://www.products.com"
        elementFormDefault="qualified"
        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"
        xmlns:product="http://www.products.com">
   <include schemaLocation="Car.xsd"/>
   <element name="productinfo">
      <complexType>
         <sequence>
            <element ref="product:car" minOccurs="1" 
                     maxOccurs="1"/>
            <element name="price" type="string" 
                     minOccurs="1" maxOccurs="1"/>
         </sequence>
      </complexType>
   </element>
</schema>

Observe that this schema has a namespace: http://www.products.com.  Also
note that it <include>s Cars.xsd.  This results in the schema
incorporating into the namespace all the components in the Cars.xsd
schema (in this case, just one component - car).  Effectively, it's as
though car had been defined inline in ProductInfo.xsd.  

Now that the car element is incorporated into the namespace this schema
then uses its definition in productinfo's content model:

            <element ref="product:car" minOccurs="1" 
                     maxOccurs="1"/>

Thus we see the ability for a schema with a namespace to incorporate
components from another schema with no namespace, and have those
no-namespace components become members of the namespace.  I do not show
it, but instead of <include> I could alternatively has used <redefine>
and it would achieve the same result (see Eric van der Vlist's message).

The schema for the <userreviewsummary> is defined in an exactly
analogous fashion - it defines a targetNamespace, <include>s Cars.xsd
which results in the components in Cars.xsd being incorporated into the
namespace.  At the bottom of this message I show UserReviewSummary.xsd.

So the same no-namespace component, <car>, is able to incorporate into
names.  This is the Chameleon effect.

It is up to each schema that incorporates the Chameleon components to
decide on the semantics for the Chameleon components in that context
(i.e., that namespace).  In Cars.xsd it defined the structure and type
of the car element.  If we can agree that the "semantics" is more than
just structure and type information then it follows that those schemas
which incorporate the car element into their namespace must provide that
"extra" information to define the semantics of car (e.g., it might
provide an annotation describing to tools how it should behave when it
encounters a <car> element).

So, not only can the Chameleon components incorporate into many
different namespaces, but also, they can have multiple different
semantics, i.e., different semantics in each schema they are used
within.

Now I think it is easy to see why last week I listed these advantages of
Chameleon components:

> - 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 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!

[Does this help Sam?]

Finally, here is the schema that I spoke about above:

UserReviewSummary.xsd

<?xml version="1.0"?>
<schema xmlns="http://www.w3.org/2000/10/XMLSchema"
        targetNamespace="http://www.reviews.com"
        elementFormDefault="qualified"
        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"
        xmlns:review="http://www.reviews.com">
   <include schemaLocation="Car.xsd"/>
   <element name="userreviewsummary">
      <complexType>
         <sequence>
            <element name="productreviewed">
                <complexType>
                    <sequence>
                        <element ref="review:car" 
                                 minOccurs="1" maxOccurs="1"/>
                    </sequence>
                </complexType>
            </element>
            <element name="rating" minOccurs="1" maxOccurs="1">
                <complexType>
                    <simpleContent>
                        <extension base="decimal">
                            <attribute name="max"
                             type="nonNegativeInteger" use="required"/>
                        </extension>
                    </simpleContent>
                </complexType>
            </element>
         </sequence>
      </complexType>
   </element>
</schema>





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS