[
Lists Home |
Date Index |
Thread Index
]
>
>
>It was a typo/mixup. The schema violated the "child validates a subset of what the parent can validate" informal rule that I use for remembering how to derivation by restriction works. I should have attempted to validate it instead of composing it inline. :)
>
Yes, this is a good way to determine if a restriction is valid or not
and I've used it myself on a number of occasions in the form it's
written in the Primer [1]:
"In other words, an application prepared for the values of the base type
would not be surprised by the values of the restricted type."
This is a very good rule where it applies but unfortunately it doesn't
apply to all cases. For example, the schema used by Kawaguchi-san in his
article is the following:
/Base type:/
<xs:all>
<xs:element name="a" />
<xs:element name="b" />
<xs:element name="c" minOccurs="0" />
<xs:all>
/New type derived by restriction:
/<xs:all>
<xs:element name="b" />
<xs:element name="a" />
<xs:all>
This does indeed pass the above rule since an instance with (b, a) or
(a, b) is valid against the base type. Unfortunately this is not a valid
restriction since the order of the element declarations have been
swapped for a and b in the restricted type. Another example where the
above rule doesn't always apply is when you change the model group
(sequence, choice or all) in the restricted type to be something
different than the model group of the base type.
>>XML Spy4.4 and MSXML4 both (incorrectly) says the above type derivation is valid
>>
>>
>
>Thanks for the heads up, I'll file a bug about this.
>
Great!
Cheers,
/Eddie
|
