[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XML Schema to relaxNG xslt

xmlspy nillable

Dare Obasanjo wrote:


>>How does one restrict complex types in WXS?
I'm sure complex type restriction is useful in many case but I think it 
is very important to mention that deriving complex types by restriction 
is no walk in the park. The rules for what is an allowed restriction 
when dealing with complex types are very complex and my tongue keeps 
ending up in a knot when I read this part of the spec. Due to this 
complexity it is my belief that many will simply do trial and error to 
see if the restriction they came up with was valid or not using the 
validator. However, since the spec is so complicated this is also the 
part where different validators will differ so a trial and error 
definately won't guarantee the result.
More comments below.

>A restriction of a complex type is a type that validates a subset of
>what the base type does. An example is 
><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
> <!-- base type -->
> <xs:complexType name="XML-Deviant">
>  <xs:sequence>
>   <xs:element name="numPosts" type="xs:integer" minOccurs="0"
>maxOccurs="1" /> 
>   <xs:element name="signature" type="xs:string" nillable="true" />
>  </xs:sequence>
>  <xs:attribute name="firstSubscribed" type="xs:date" use="required" />
>  <xs:attribute name="mailReader" type="xs:string"/>
> </xs:complexType>
> <!-- derived type --> 
>  <xs:complexType name="DareObasanjo">
>   <xs:complexContent>
>   <xs:restriction base="XML-Deviant">
>   <xs:sequence>
>    <xs:element name="numPosts" type="xs:integer" minOccurs="1" /> 
>    <xs:element name="signature" type="xs:string" nillable="false" />
>   </xs:sequence>
>   <xs:attribute name="firstSubscribed" type="xs:date" use="optional" />
>   <xs:attribute name="mailReader" type="xs:string" fixed="Microsoft
>Outlook" />
>   </xs:restriction>
>   </xs:complexContent>
>  </xs:complexType> 
The problem with complex type derivation by restriction is that you 
_HAVE_ to understand the spec in order to use it. In many cases you have 
a restriction that looks perfectly valid when you look at the schema but 
this doesn't mean it's valid. I was going to give an example of a type 
derivation which looks valid but isn't but then I had a closer look at 
the above example and saw that I don't have to provide an invalid 
example because we already have one. The above looks perfectly valid at 
a first glance but when you pick up the magnifier glass you will find 
that the base type has a required attribute "firstSubscribed" which is 
made optional in the derived type. This is not a valid restriction 
because you can never remove anything that is required in the base type. 
I'm not sure if this was a simple typo by Dare or if he wasn't aware 
that this was indeed an illegal derivation. To illustrate the point that 
different tools handle derivation by restriction differently I tested 
the above with the following validators: XMLSpy 4.4, XSV, SQC, MSXML4 
and Xerces 2.0.1.

Here are the results:

XML Spy4.4 and MSXML4 both (incorrectly) says the above type derivation 
is valid

XSV and Xerces (correctly) complains that the type derivation is invalid 
due to the attribute "firstSubscribed" being optional in the derived type.

SQC complains about the above but it also gives the following error:

TYPE REFINEMENT ERROR (content type incompatible with the content type 
of the basetype):
In the definition of complexType DareObasanjo, elementOnly content model (
<xs:sequence maxOccurs="1" minOccurs="1">
    <xs:element maxOccurs="1" minOccurs="1" name="numPosts" 
nillable="false" type="xs:integer"/>
    <xs:element maxOccurs="1" minOccurs="1" name="signature" 
nillable="false" type="xs:string"/>
is not a restriction of elementOnly content model (
<xs:sequence maxOccurs="1" minOccurs="1">
    <xs:element maxOccurs="1" minOccurs="0" name="numPosts" 
    <xs:element maxOccurs="1" minOccurs="1" name="signature" 
nillable="true" type="xs:string"/>
the content type defined by the basetype.

I'm not sure if this is indded an error that the others have missed or 
if SQC is incorrect but my guess is that the error relates to how 
nillable can be modified in a restriction. I can't find this in the spec 
so I'll leave it to others to decide if SQC is wrong and the others 
correct or vice versa.
The point is that complex type derivation by restriction is an evil 
beast and if you don't have expert knowledge of this part of the spec 
you may be swimming in very deep water. Kawaguchi-san wrote an 
interesting article about this a couple of months ago [1] where he gives 
another example of a derivation by restriction that look correct but isn't.


[1] http://www.xml.com/pub/a/2001/06/06/schemasimple.html?page=1


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.