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



> Subject: Implementing variable content containers using
>          "dangling types".

I think your technique causes an interoperability problem.


>           <xsd:import namespace="http://www.sensor.org"/>
> 
>           The instance document must then identify a schema
>           that defines sensor_type.  Thus, at run time
>           we are matching up the reference to sensor_type
>           with the implementation of sensor_type.  Wow!

Validators are not required to honor schemaLocation attributes nor
import elements. Nor there is no guarantee that your validator parses
additional schemata found at the run time. In fact, I believe MSXML4.0
doesn't honor xsi:schemaLocation at all.

It is completely legal to abandon validating sensor_type and make
validation fail.


Although I think your idea is a cool trick, you don't want to list it as
a "best practice" for the above reason.

A good schema should avoid possible pitfalls, shouldn't it.





Also, I read http://www.xfront.com/BestPractices.html and found several
wrong statements. (Or it is me who is wrong, but I want to find out who
is wrong.)


"Default namespace - targetNamespace or XMLSchema?"
==============================================================

In "analysis of the three approaches", you wrote 

> this impact Book's reference to CardCatalogueEntry in the BookCatalogue schema? 
>    <xsd:element name="Book" type="CardCatalogueEntry"/>
> 
> Since there is no namespace qualifier on CardCatalogueEntry it is
> referencing the default namespace. What is the default namespace?
> XMLSchema is the default namespace.

It's wrong. The default namespace is the no-namespace. It doesn't matter
who includes the chameleon module.

It has nothing to do with XML Schema. It's a simple problem of how QName
is resolved into (URI,local name) pair, and the default namespace in
this case is no-namespace because your XML is:

---------------------------------------
<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2000/10/XMLSchema"
        elementFormDefault="qualified">
    <xsd:complexType name="CardCatalogueEntry">
        <xsd:sequence>
            <xsd:element name="Title" type="xsd:string"/>
            <xsd:element name="Author" type="xsd:string"/>
            <xsd:element name="Date" type="xsd:string"/>
            <xsd:element name="ISBN" type="xsd:string"/>
            <xsd:element name="Publisher" type="xsd:string" />
        </xsd:sequence>
    </xsd:complexType>
    <xsd:element name="Book" type="CardCatalogueEntry"/>
</xsd:schema>
---------------------------------------

So a qname "CardCatalogueEntry" is resolved to
(no-NS,"CardCatalogueEntry") pair.

The above schema file doesn't work regardless of who includes it. 
There is no way to refer to "CardCatalogueEntry" from "Book" element
declaration.

(The spec describes QName resolution in the section 3.15.2.1)

So we should rather say that chameleon modules are very difficult to use
and good citizens need to avoid them as much as possible.




"Hide(Localize) Namespace vs Expose Namespace"
==============================================================

Your "Camera.xml (namespaces hidden)" is wrong.

---------------------------------------
<?xml version="1.0"?>
<my:camera xmlns:my="http://www.camera.org"
         xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
         xsi:schemaLocation=
                   "http://www.camera.org
                    Camera.xsd">
    <body>
        <description>Ergonomically designed casing for easy handling</description>
    </body>
    <lens>
        <zoom>300mm</zoom>
        <f-stop>1.2</f-stop>
    </lens>
    <manual_adapter>
        <speed>1/10,000 sec to 100 sec</speed>
    </manual_adapter>
</my:camera>
---------------------------------------

<body>,<lens>, and <manual_adapter> are right. They should be
unqualified. But you still need to qualify <description>,<zoom>,<f-stop>
and <speed> because they are global declarations.

You have to qualify elements when they are global. It doesn't matter
whether elementFormDefault is qualified or unqualified. As a result,
your rationale to the "hide-namespace" design becomes questionable.
The first two items regarding readability becomes wrong because you
don't gain any readability advantage, and the third item:

> when you need the flexibility of being able to change the schema
> without impact to instance documents. ...

The opposite is the case. Since global elements has to be qualified
anyway, you should use elementFormDefault="qualified" if you want to
change the schema without any impact to instance documents.


In fact, there is no reason to use elementFormDefault="unqualified". As
a best practice, you should state that elementFormDefault="unqualified"
is strongly discouraged.

I just don't understand why the default value of elementFormDefault is
"unqualified" It is utterly confusing.




Multi-Schema Project: Zero, One, or Many Namespaces?
==============================================================

First, you can redefine any components in any namespace. You just need
one extra layer if you want to redefine components in the other
namespace.

And it seems to me that your analysis misses the most important point;
namely, reusability of instance documents.  By saying chameleon schema
is a preferable approach, you end up creating instances like

<foo xmlns="companyA">
  <department>
    <person>
      <first> Joe </first>
      <last> Black </last>
    </person>
  </department>
</foo>

<foo xmlns="companyB">
  <department>
    <person>
      <first> George </first>
      <last> Bush </last>
    </person>
  </department>
</foo>

How can others recognize that person elements have the same semantics?
One more reason to avoid chameleon module.

This is also another reason to avoid unqualified local elements.



Creating Variable Content Container Elements
==============================================================

In "advantages" of method 1, you wrote

>    <Catalogue>
>         <Book> ... </Book>
>         <CD> ... </CD>
>         <Magazine> ... </Magazine>
>         <Book> ... </Book>
>    </Catalogue>

But you can't do this. You will do <CD:CD> ... </CD:CD>. If you are not
allowed to modify Catalogue schema, that means you can't add any element
declaration in that namespace. <CD> element has to be in a different
namespace.


Enough to call it a day.

regards,
--
Kohsuke KAWAGUCHI                          +1 650 786 0721
Sun Microsystems                   kohsuke.kawaguchi@eng.sun.com