Re: Extending abstract elements with a choice

Hi Shane,

Your schema is not valid. You cannot restrict a sequence with a choice, 
this is forbidden, see
http://www.w3.org/TR/xmlschema-1/#cos-particle-restrict

If you use extension instead of restriction then your schema is also 
invalid as it violates the Unique Particle Attribution
http://www.w3.org/TR/xmlschema-1/#cos-nonambig

the content model will be:
((Object1{0-1}, Object2{0-1}), (SpecialObject1 | (Object1, Object2)))

and when the parser encounters Object1 it will not know what particle to 
follow, either Object1{0-1} or Object1.

Hope that helps,
George
-----------------------------------------------
George Cristian Bina
<oXygen/> XML Editor & XSLT Editor/Debugger
http://www.oxygenxml.com

Shane Lauf wrote:
> George,
> 
> Thanks again for your help. Your approach worked perfectly, though I now
> realise there was a bug in my original question. In the "semantically
> equivalent to..." bit, it should have been
>        <xsd:element ref="Object1"/>
>        <xsd:element ref="Object2"/>
> i.e. without the minOccurs="0" on each of these. I changed this in your
> solution and it started giving me the (correct) validation errors I was
> hoping for when the child elements weren't present in myConcreteElement.
> 
> That said, I think I may have managed to do it in one go without the tmp
> Type.
> 
> <?xml version="1.0"?>
> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
>  <xsd:element name="test">
>   <xsd:complexType>
>    <xsd:sequence>
>     <xsd:element ref="myAbstractElement"/>
>    </xsd:sequence>
>   </xsd:complexType>
>  </xsd:element>
>  <xsd:element name="myAbstractElement" type="myAbstractElementType"
> abstract="true"/>  <xsd:complexType name="myAbstractElementType">
>   <xsd:sequence>
>    <xsd:element ref="Object1" minOccurs="0"/>
>    <xsd:element ref="Object2" minOccurs="0"/>
>   </xsd:sequence>
>  </xsd:complexType>
>  <xsd:element name="myConcreteElement"
> substitutionGroup="myAbstractElement">
>   <xsd:complexType>
>    <xsd:complexContent>
>     <xsd:restriction base="myAbstractElementType">
>      <xsd:choice>
>       <xsd:element ref="SpecialObject1"/>
>       <xsd:sequence>
>        <xsd:element ref="Object1"/>
>        <xsd:element ref="Object2"/> 
>        <!-- note - had to remove the minOccurs="0" on these two-->
>       </xsd:sequence>
>      </xsd:choice>
>     </xsd:restriction>
>    </xsd:complexContent>
>   </xsd:complexType>
>  </xsd:element>
>  <xsd:element name="Object1"/>
>  <xsd:element name="Object2"/>
>  <xsd:element name="SpecialObject1"/>
> </xsd:schema>
> 
> With this, the following file (correctly) fails in the same way as your
> method, with the error "Require mandatory child elements (SpecialObject1 |
> (Object1, Object2))" using both XMLSpy and MSV.
> 
> <?xml version="1.0" encoding="UTF-8"?>
> <test xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:noNamespaceSchemaLocation="test.xsd">
> 	<myConcreteElement></myConcreteElement>
> </test>
> 
> Is this a valid way of doing things, or am I missing something?
> Interestingly, it works exactly the same doing myConcreteElement as an
> extension on myAbstractElement instead of as a restriction.
> 
> Thanks again,
> 
> Shane
> 
> 
> 
>>-----Original Message-----
>>From: George Cristian Bina [mailto:george@sync.ro]
>>Sent: Thursday, September 02, 2004 7:54 PM
>>To: Shane Lauf
>>Cc: xmlschema-dev@w3.org
>>Subject: Re: Extending abstract elements with a choice
>>
>>Hi Shane,
>>
>> > There's
>> > no way to do it in one go (i.e. without the tmp element), right?
>>
>>That is a type not an element. AFAIK yes, you need to have an additional
>>type.
>>
>>Best Regards,
>>George
>>-----------------------------------------------
>>George Cristian Bina
>><oXygen/> XML Editor & XSLT Editor/Debugger
>>http://www.oxygenxml.com
>>
>>Shane Lauf wrote:
>>
>>>George,
>>>
>>>Thanks very much for the quick reply on this - I'll give it a try.
> 
> There's
> 
>>>no way to do it in one go (i.e. without the tmp element), right?
>>>
>>>Shane
> 
> 
> 
>

Received on Friday, 3 September 2004 07:29:39 UTC