Hi Ralf,

That is an interesting approach! I would make the impossible element 
abstract instead of defining it to contain itself recursively:

<xs:element name="impossible" final="#all" abstract="true"/>

This has the advantage that the definition is shorter and the impossible 
element should not be presented by content completion hints because it 
is abstract.

Now it is hard to say what part of the algorithm from the XML Schema 
specification rejects the empty sequence but anyway it is clear that the 
content of the restricted type can be empty while the content of the 
base type cannot be empty which is clearly wrong.

Thanks for catching that,
George
---------------------------------------------------------------------
George Cristian Bina
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
www.---.com


Ralf Lammel wrote:
> But hold on ...
> 
> 1. <sequence/> is not pointless (in an algebraic sense certainly not) *when* placed as a branch of a choice simply because it makes the entire choice optional (if it wasn't yet before).
> 
> 2. Hence, I don't see why Xerces is doing the right thing when it accepts the proposed fix with the empty sequence as part of the restricted choice. For curiosity, I tried some other validator, and indeed, it would accept this fix.
> 
> 3. Or was the idea to add the empty sequence to *both* base type and restricted type? But this wouldn't be semantics-preserving either, not in even in the special case posted. (The base-type semantics did not comprise the empty content as far as I can see.)
> 
> 4. I do agree in so far that we are suffering here from a really wild semantics of subtyping choices in the context of restriction here. Let's simplify your example to get rid of feature interaction with groups. This scheme of restriction still works:
> 
> <?xml version="1.0" encoding="UTF-8"?>
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
>   <xs:element name="a1" type="xs:string"/>
>   <xs:element name="a2" type="xs:string"/>
>   <xs:element name="b" type="xs:string"/>
>   <xs:element name="c" type="xs:string"/>
>   <xs:complexType name="baseType">
>     <xs:choice>
>       <xs:choice maxOccurs="unbounded">
>         <xs:element ref="a1"/>
>         <xs:element ref="a2"/>
>       </xs:choice>
>       <xs:element ref="b"/>
>       <xs:element ref="c"/>
>     </xs:choice>
>   </xs:complexType>
>   <xs:complexType name="restrictedType">
>     <xs:complexContent>
>       <xs:restriction base="baseType">
>         <xs:choice>
>           <xs:choice maxOccurs="unbounded">
>             <xs:element ref="a1"/>
>             <xs:element ref="a2"/>
>           </xs:choice>
>           <xs:element ref="b"/>
>         </xs:choice>
>       </xs:restriction>
>     </xs:complexContent>
>   </xs:complexType>
> </xs:schema>
> 
> So the restriction has indeed removed one branch of the choice.
> This schema still validates fine.
> If we now tried to remove one more branch ...
> 
>   <xs:complexType name="restrictedType">
>     <xs:complexContent>
>       <xs:restriction base="baseType">
>         <xs:choice>
>           <xs:choice maxOccurs="unbounded">
>             <xs:element ref="a1"/>
>             <xs:element ref="a2"/>
>           </xs:choice>
>           <!-- <xs:element ref="b"/> -->
>         </xs:choice>
>       </xs:restriction>
>     </xs:complexContent>
>   </xs:complexType>
> 
> ... but then we run into the sort of problem of the OP.
> 
> The problem is indeed that the outer choice becomes sort of pointless.
> Algebraically, it makes *totally* sense that the above (2nd) restriction is treated the same as the following (with the pointless choice eliminated):
> 
>   <xs:complexType name="restrictedType">
>     <xs:complexContent>
>       <xs:restriction base="baseType">
>         <xs:choice maxOccurs="unbounded">
>           <xs:element ref="a1"/>
>           <xs:element ref="a2"/>
>         </xs:choice>
>       </xs:restriction>
>     </xs:complexContent>
>   </xs:complexType>
> 
> Algebraically, it is not acceptable that this restriction is not valid with regard to the original base type anymore. (And again, algebraically, it is not acceptable "to make it work" by adding an empty sequence branch.) So if the XSD spec or the XSD implementation or both doesn't/don't know about the algebra of regular expressions (or it least does not use it for the notion of subtyping in restriction), then we can try to fix this as follows:
> 
> a) We define the impossible element declaration:
> 
>   <xs:element name="impossible" final="#all">
>     <xs:complexType>
>       <xs:sequence>
>         <xs:element ref="impossible"/>
>       </xs:sequence>
>     </xs:complexType>
>   </xs:element>
> 
> BTW, the fact that this element declaration is definable is a sort of interesting property of XSD anyhow, but it really helps here.
> 
> b) We define the base type to also comprise an impossible branch:
> 
>   <xs:complexType name="baseType">
>     <xs:choice>
>       <xs:element ref="impossible"/>
>       <xs:choice maxOccurs="unbounded">
>         <xs:element ref="a1"/>
>         <xs:element ref="a2"/>
>       </xs:choice>
>       <xs:element ref="b"/>
>       <xs:element ref="c"/>
>     </xs:choice>
>   </xs:complexType>
> 
> Again, one might argue that the impossible element is *kind* of pointless but XSD implementations are not allowed to see this (and optimize the particle away) because the spec doesn't identify this sort of pointlessness.
> 
> c) Hence, the offending restriction does not contain any pointless choice anymore, and the following works:
> 
>   <xs:complexType name="restrictedType">
>     <xs:complexContent>
>       <xs:restriction base="baseType">
>         <xs:choice>
>           <xs:element ref="impossible"/>
>           <xs:choice maxOccurs="unbounded">
>             <xs:element ref="a1"/>
>             <xs:element ref="a2"/>
>           </xs:choice>
>         </xs:choice>
> 
> 
> Regards,
> Ralf Laemmel
> Webdata/XML, Microsoft
> http://homepages.cwi.nl/~ralf/
> 
> 
>> -----Original Message-----
>> From: xmlschema-dev-request@w... [mailto:xmlschema-dev-request@w...]
>> On Behalf Of richard.liu@u...
>> Sent: Monday, February 13, 2006 6:56 AM
>> To: mike@s...; george@o...
>> Cc: xmlschema-dev@w...
>> Subject: RE: E rcase-RecurseLax.1: Group's occurrence range,
>> (1,unbounded), is not a valid restriction of base group's occurrence
>> range, (1,1).
>>
>>
>> George, Michael,
>>
>> Thanks to both of you for your insights.  As usual, you're both right.
>> Adding the pointless sequence satisfies Xerces, as George suggests.  And,
>> as Michael suggests, this is totally counter-intuitive.
>>
>> Regards,
>> Richard
>>

From ralf.lamme