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

Re: XML Schema to relaxNG xslt

• To: Dare Obasanjo <dareo@m...>
• Subject: Re: XML Schema to relaxNG xslt
• From: Eddie Robertsson <erobertsson@a...>
• Date: Mon, 24 Jun 2002 11:28:18 +1000
• Cc: John Cowan <jcowan@r...>, Rick Taylor <taylor@p...>, xml-dev@l...
• References: <8BD7226E07DDFF49AF5EF4030ACE0B7E06621D32@r...>
• User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530

Hi,

Dare Obasanjo wrote:

</snip>

>>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> 
>
>
></xs:schema>
>  
>
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"/>
</xs:sequence>
)
is not a restriction of elementOnly content model (
<xs:sequence maxOccurs="1" minOccurs="1">
    <xs:element maxOccurs="1" minOccurs="0" name="numPosts" 
type="xs:integer"/>
    <xs:element maxOccurs="1" minOccurs="1" name="signature" 
nillable="true" type="xs:string"/>
</xs:sequence>
),
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.

Cheers,
/Eddie

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

• Follow-Ups:
  • Re: XML Schema to relaxNG xslt
    • From: Jeni Tennison <jeni@j...>

• References:
  • RE: XML Schema to relaxNG xslt
    • From: "Dare Obasanjo" <dareo@m...>

• Prev by Date: Updated on 6
• Next by Date: RE: XML Schema to relaxNG xslt
• Previous by thread: RE: XML Schema to relaxNG xslt
• Next by thread: Re: XML Schema to relaxNG xslt
• Index(es):
  • Date
  • Thread