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


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: XML Schemas: Best Practices


My apologies for being so far behind the times-- I wanted to have some time
to spend with these.  This "Best Practices" issue is about default
namespaces and Chameleon components.

[snip throughout...]

> <?xml version="1.0"?>
> <schema xmlns="http://www.w3.org/2000/10/XMLSchema"
>         targetNamespace="http://www.library.org"
>         xmlns:lib="http://www.library.org"
>         elementFormDefault="qualified">
>     <include schemaLocation="BookCatalogue.xsd"/>
>     <element name="Library">
>         <complexType>
>              <sequence>
>                  <element name="BookCatalogue">
>                      <complexType>
>                          <sequence>
>                              <element ref="lib:Book"
>                                 minOccurs="0" maxOccurs="unbounded"/>
>                          </sequence>
>                      </complexType>

Should there be a closing element tag here?  I don't think this is important
for sake of the example-- only if this exact example is published as a Best
Practice.  (The WF error also occurs in Approach 2).

>             </sequence>
>         </complexType>
>     </element>
> </schema>

> With this second approach all the components used to create a schema are
> namespace qualified (with xsd).

This is actually the approach I use.

> Before describing why I believe that approach 2 is better, we need to
> first revisit Chameleon components.
> Components that are in a schema with no targetNamespace have a very
> interesting property: when they are <include>d in a schema that has a
> targetNamespace then those no-namespace components take on the namespace
> of the <include>ing schema.  They "blend into the background" just like
> a Chameleon.  Thus, the no-namespace components are called Chameleon
> components.
> In the above schemas there is an <include> element to bring in the
> components in BookCatalogue.xsd.  Let's consider how the above
> approaches behave when the schema being <include>d (BookCatalogue.xsd)
> has no namespace.  Here is BookCatalogue.xsd:

Wow, what a great description.  Do you happen to have any other references
for this?  It seems as though stuff like this may in fact affect other Best
Practices or decisions therein.  This also seems like a good one for the
Schema FAQ-- What is a chameleon component?

> Since there is no namespace qualifier on CardCatalogueEntry it is
> referencing the default namespace.  What is the default namespace?  The
> targetNamespace is the default namespace. Thus, this reference is to
> CardCatalogueEntry in the default namespace, which is exactly where it's
> at!

It is exactly where it is at, but is that always what you want?  I actually
like the ability of chameleon components to blend-- and I think if you
didn't want that ability then simply include a target namespace, so I think
Approach 2 should be best practice, as you said (are you going to give a
prefix as best practice? e.g. "xsd:" <ducks/>)--

Is there an Approach 3? (a.k.a. is this even right?)

Approach 3 would prefix both and not have a default namespace

<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2000/10/XMLSchema"
    <xsd:include schemaLocation="BookCatalogue.xsd"/>
    <xsd:complexType name="LocalType">
             <xsd:element name="LocalElement" type="xsd:string"
                minOccurs="0" maxOccurs="unbounded"/>
    <xsd:element name="Library">
                 <xsd:element name="BookCatalogue">
                             <xsd:element ref="Book"
                                minOccurs="0" maxOccurs="unbounded"/>
                             <xsd:element name="somelocalelement"
                                minOccurs="0" maxOccurs="unbounded"/>

Notice niether Book or LocalType are prefixed because there is no default
namespace.  This has the same ultimate effect of Approach 2.-- it is just a
bit akward.  I suppose that maybe this is a gray area (at least for me)--
but I keep thinking there may be some valuable workaround here.  Either way
I think Approach 2 is the Best Practice-- this is even how the Primer lays
it out.

Thanks again Roger,
Jeff Rafter