Re: ANN: XML Schema: DOs and DON'Ts

[Eddie Robertsson <eddie@allette.com.au>]

Hi,

I've also just read through your document and I have a few observations.
You write:

1) "DO use XML namespaces as much as possible. Learn the correct way to
use it."

A agree that you should learn how to use XML Namespaces but I'd be more
careful when it comes to the "correct" way. You make a good point in your
article but at the same time Martin gave another example of how he (and
probably others) use it so I wouldn't call your way "the correct way" of
using namespaces.

2) You also write:

"Second, even if you write the restriction correctly, you may get an
error from your validator. Consider the following example:

Base type:
<xs:all>
  <xs:element name="a" />
  <xs:element name="b" />
  <xs:element name="c" />
</xs:all>

New type derived by restriction:
<xs:all>
  <xs:element name="b" />
  <xs:element name="a" />
</xs:all>

The latter looks like a proper restriction of the former. But XML Schema
prohibits this."

What exactly is the problem with this. I'm no expert on XML Schemas (I
agree that mastering XML Schemas is very difficult) but I believe the
following is a valid schema with a valid restriction that conforms to the
above specification:

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
 <xsd:element name="restriction" type="restrictedType"/>
 <xsd:complexType name="baseType">
  <xsd:all>
   <xsd:element name="a" type="xsd:string"/>
   <xsd:element name="b" type="xsd:string"/>
   <xsd:element name="c" type="xsd:string"/>
  </xsd:all>
 </xsd:complexType>
 <xsd:complexType name="restrictedType">
  <xsd:complexContent>
   <xsd:restriction base="baseType">
    <xsd:all>
     <xsd:element name="b" type="xsd:string"/>
     <xsd:element name="a" type="xsd:string"/>
    </xsd:all>
   </xsd:restriction>
  </xsd:complexContent>
 </xsd:complexType>
</xsd:schema>

I tried validating this with XSV and it seems to be valid. Isn't this
what you were trying to do?

3) I haven't made up my mind yet what I think about Cameleon schemas but
I definately know that it is a very advanced feature of XML Schema that
shouldn't be used until you are comfortable with more "normal" features.
However, I believe you are mistaken in your comments about the example
you use:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <!-- note that targetNamespace attribute is absent. -->
  <xs:element name="person">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="familyName" />
        <xs:element ref="lastName" />
      </xs:sequence>
    </xs:complexType>
  </xs:element>
  <xs:element name="familyName" type="xs:string"/>
  <xs:element name="lastName" type="xs:string"/>
</xs:schema>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
           targetNamespace="http://best.practice.com"
xmlns="http://best.practice.com">
    <!-- I have added 'xmlns="http://best.practice.com"' -->

  <xs:include schemaLocation="above.xsd" />

  <xs:element name="root">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="person" maxOccurs="unbounded" />
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

I think this is a perfectly valid schema without you having to change
anything in the included schema (if you add
xmlns="http://best.practice.com" to your including schema). The feature
of Cameleon schemas are that the no-namespace components in your included
schema, i.e family, lastName and familyName will take on the
targetNamespace of the including schema. This means that family, lastName
and familyName will all be in the namespace "http://best.practice.com"
after the inclusion. In your including schema you also say that the
default namespace is "http://best.practice.com" which means the
unqualified declarations in your included schema will use this default
namespace. This is the way I have understood the Cameleon schemas to work
but then again this is very complicated and I could very well be
completely wrong.

Cheers,
/Eddie