[
Lists Home |
Date Index |
Thread Index
]
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
|
