Re: Substitution groups - replacing required elements in the s.group head

Thanks George. If there's no way to go forward without 
changing the original schema as well, then the abstract 
elements idea sounds like it will be the best solution. I'd 
like to exhaust the other options (which leave the original 
schema intact) first though. Can you think of anything else 
("extending" with a minOccurs="0", or something?) that might 
be feasible?

Regards,

Shane

---- Original message ----
>Date: Mon, 02 Aug 2004 13:13:16 +0300
>From: George Cristian Bina <george@sync.ro>  
>Subject: Re: Substitution groups - replacing required 
elements in the s.group head  
>To: Shane Lauf <srl01@uow.edu.au>
>Cc: xmlschema-dev@w3.org
>
>Hi Shane,
>
>You can define an abstract element like:
>
><xsd:element name="abstractObject" abstract="true"/>
>
>and then use that in the content model of the container:
>
><xsd:element name="myContainer">
>   <xsd:complexType>
>     <xsd:sequence>
>       <xsd:element ref="abstractObject"/>
>     </xsd:sequence>
>   </xsd:complexType>
></xsd:element>
>
>Add the myObject in the substitution group for the 
abstractObject
>
><xsd:element name="myObject" type="myObjectType" 
>substitutionGroup="abstractObject"/>
>
>and do the same for the new myOtherObject element:
>
><xsd:element name="myOtherObject" type="myOtherObjectType" 
>substitutionGroup="abstractObject"/>
><xsd:complexType name="myOtherObjectType">
>   <xsd:sequence>
>     <xsd:element name="forwardingaddress" 
type="xsd:string"/>
>   </xsd:sequence>
></xsd:complexType>
>
>Hope that helps,
>George
>-----------------------------------------------
>George Cristian Bina
><oXygen/> XML Editor & XSLT Editor/Debugger
>http://www.oxygenxml.com
>
>
>Shane Lauf wrote:
>> I am running in to a problem with substitution groups when 
the substitution
>> group head includes a required element. For an element 
which I would like to
>> include in the substitution group, I would like the 
required element to be
>> replaced by a different element which is not substitutable 
for the required
>> element. 
>> 
>> For example, I have a myObject element (think "postal 
letter") of type
>> myObjectType, defined to include either a "pobox" or some 
number of
>> "streetaddress"es. (i.e. it has to have at least one or 
the other.)
>> 
>> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
>>   <xsd:element name="myContainer">
>>     <xsd:complexType>
>>       <xsd:sequence>
>>         <xsd:element ref="myObject"/>
>>       </xsd:sequence>
>>     </xsd:complexType>
>>   </xsd:element>
>>   <xsd:element name="myObject" type="myObjectType"/>
>>   <xsd:complexType name="myObjectType" mixed="true">
>>     <xsd:sequence>
>>       <xsd:choice>
>>         <xsd:element name="pobox" type="string"/>
>>         <xsd:element name="streetaddress" type="string"
>> maxOccurs="unbounded"/>
>>       </xsd:choice>
>>     </xsd:sequence>
>>   </xsd:complexType>
>> </xsd:schema>
>> 
>> Example usage: 
>> <myObject><pobox>12345</pobox></myObject>
>> <myObject><streetaddress>12345 Smith 
Ave.</streetAddress></myObject>
>> 
>> I would like to define a myOtherObject which can have 
a "forwardingaddress"
>> instead of the "pobox" or "streetaddress"es:
>> 
>> <myOtherObject><forwardingaddress>12345 Jones
>> Ave.</forwardingaddress></myOtherObject>
>> 
>> The crunch is that I also need myOtherObject to 
*substitute* for myObject
>> under myContainer. However if I declare myOtherObject to 
have
>> substitutionGroup="myObject", it seems to have to be to be 
a derivation from
>> myObjectType - thereby inheriting the requirement to have 
either a "pobox"
>> or a "streetaddress". Is there some way I can:
>> 
>> * substitute for, without deriving from (extending), 
myObjectType;
>> * extend myObjectType with a minOccurs="0" on the elements 
in the choice; or
>> * extend myObjectType with another possible element 
(forwardingaddress) in
>> the choice
>> 
>> .... allowing me to get around the one-or-the-other
(pobox|streetaddress)
>> restriction - and leave the original schema intact?
>> 
>> SRL
>> 
>> 
>

Received on Monday, 2 August 2004 21:35:29 UTC