Re: [xml-dev] Perplexing Invalid Schema

[Michael Kay <mike@saxonica.com>]

On 11/09/2012 19:49, Timothy Cook wrote:
> Thanks Michael.  Apologies that I did not notice that it wasn't
> initially sent to the list.  Just my habit of being sure a thread on
> the list is always there.
>
> Back to the subject.  I understand your explanation.  However, I
> cannot conclude that there is a technical reason for not allowing
> this.  Derivation allows for both extension and restriction.  In this
> case it seems to me that first derivation should be checked and then
> test for content of the derived type.
This area of the spec has been significantly revised for XSD 1.1, and 
some of the unnecessary limitations have been removed, but the 
constraint remains that only derivation by restriction is allowed here, 
not derivation by extension. So there is good evidence that the rule is 
deliberate and not an oversight.

I think the principle is that when a type is derived by restriction, 
instances of that type cannot have any content that would not be allowed 
in the base type. If we allowed a child whose type was derived by 
extension, then an element belonging to the restricted type could have a 
grandchild that would not be permitted as a grandchild of an element 
belonging to the base type.

But I must admit that it doesn't seem to be significantly different from 
introducing a member of a substitution group, where derivation by 
extension is permitted. I'm afraid that despite my years on the schema 
WG, the logic of the spec frequently eludes me. Often I am reduced to 
implementing the rules without asking too many questions about why they 
are there.

As to using OO design principles in schema design, I find that the 
analogies quickly break down. Should the type of <heading> be derived by 
restriction from <paragraph>, or should the type of <paragraph> be 
derived by extension from <heading>? When designing databases, I would 
ask ontological questions to get an answer (Is every employee a 
person?). I've never found that works when designing documents.

Michael Kay
Saxonica
>
> For example:
> Is 'Any' an ancestor of  'DT1-1'? - Yes.
> Are each of the extensions and restrictions specified in the ancestry
> tree satisfied in DT1-1? - Yes.
>
> Is this reasonable?  If anyone can speak to why the specs read the way
> they do; I would appreciate it.  My intuition tells me that it is an
> artifact of the process and that the use case I describe didn't come
> up during the specification process.
>
> Thoughts?
>
> Thanks,
> Tim
>
>
>
> On Tue, Sep 11, 2012 at 12:32 PM, Michael Kay <mike@saxonica.com> wrote:
>> Posting my reply to the list for completeness... MK
>>
>> On 11/09/2012 15:44, Michael Kay wrote:
>>>
>>> Saxon is rejecting the schema because type X is not a restriction of type
>>> Any; it is derived from Any, but some of the derivation steps involve
>>> Extension.
>>>
>>> I believe this is correct according to the specification.
>>>
>>> Section 3.4.6 Constraints on Complex Type Definition Schema Components
>>>
>>> tells us that
>>>
>>> Schema Component Constraint: Derivation Valid (Restriction, Complex)
>>>
>>> must be satisfied in respect of types Z and Item1.
>>>
>>> Clause 5.4.2 of this constraint tells us:
>>>
>>> The particle of the complex type definition itself must be a ·valid
>>> restriction· of the particle of the {content type} of the {base type
>>> definition} as defined in Particle Valid (Restriction) (§3.9.6).
>>>
>>> Section 3.9.6 Particle Valid (Restriction) tells us the element particle
>>> I-Data in Z must be a valid restriction of the element particle I-Data in
>>> Item1. Under Particle Restriction OK (Elt:Elt - NameAndTypeOK) we learn in
>>> clause 3.2.5 that this means
>>>
>>> 3.2.5 R's {type definition} is validly derived given {extension, list,
>>> union} from B's {type definition} as defined by Type Derivation OK (Complex)
>>> (§3.4.6) or Type Derivation OK (Simple) (§3.14.6), as appropriate.
>>>
>>> where R is type X and B is type Any.
>>>
>>> This takes us back to 3.4.6 which we execute with the parameter
>>> {extension, list, union}.
>>>
>>> Rule 1 of 3.4.6 says
>>>
>>> 1 If B and D are not the same type definition, then the {derivation
>>> method} of D must not be in the subset.
>>>
>>> But the subset includes "extension", so derivation by extension isn't
>>> allowed; therefore it isn't a valid restriction.
>>>
>>> Michael Kay
>>> Saxonica
>>>
>>>
>>> On 11/09/2012 14:50, Timothy Cook wrote:
>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";
>>>> elementFormDefault="qualified">
>>>>       <xs:include schemaLocation="rm-test.xsd"/>
>>>>
>>>>       <xs:element name="CCD1" type="Y"/>
>>>>
>>>>       <xs:complexType name="Y">
>>>>           <xs:complexContent>
>>>>               <xs:restriction base="ccdType">
>>>>                   <xs:sequence>
>>>>                       <xs:element name="defin" type="Z"/>
>>>>                   </xs:sequence>
>>>>               </xs:restriction>
>>>>           </xs:complexContent>
>>>>       </xs:complexType>
>>>>
>>>>
>>>>       <xs:complexType name="Z">
>>>>           <xs:complexContent>
>>>>               <xs:restriction base="Item1">
>>>>                   <xs:sequence>
>>>>                       <xs:element name="L-data" type="xs:string"
>>>> fixed="My L string."/>
>>>>                       <xs:element name="I-data" type="X"/>
>>>>                   </xs:sequence>
>>>>               </xs:restriction>
>>>>           </xs:complexContent>
>>>>       </xs:complexType>
>>>>
>>>>       <xs:complexType name="X">
>>>>           <xs:complexContent>
>>>>               <xs:restriction base="DT1-1">
>>>>                   <xs:sequence>
>>>>                       <xs:element name="A-data" type="xs:string"
>>>> fixed="My A string."/>
>>>>                       <xs:element name="dt-data" type="xs:string"
>>>> fixed="A dt string."/>
>>>>                   </xs:sequence>
>>>>               </xs:restriction>
>>>>           </xs:complexContent>
>>>>       </xs:complexType>
>>>>
>>>>
>>>>
>>>>
>>>> </xs:schema>
>>>
>
>