Hi Shane,

I think that is not possible, the main reason being that the particle 
that defines the myObjectType is not emptiable. If you add for instance 
a minOccurs="0" like below:

<xsd:complexType name="myObjectType" mixed="true">
   <xsd:sequence>
     <xsd:choice minOccurs="0">
       <xsd:element name="pobox" type="xsd:string"/>
       <xsd:element name="streetaddress" type="xsd:string" 
maxOccurs="unbounded"/>
     </xsd:choice>
   </xsd:sequence>
</xsd:complexType>

then you should be able to extend the myObjectType to add the 
forwardingaddress element:

<xsd:complexType name="tmpType" mixed="true">
   <xsd:complexContent>
     <xsd:extension base="myObjectType">
       <xsd:sequence>
         <xsd:element name="forwardingaddress" type="xsd:string"/>
       </xsd:sequence>
     </xsd:extension>
   </xsd:complexContent>
</xsd:complexType>

and then restrict it to remove the pobox and streetaddress in the 
myOtherObjectType:

<xsd:complexType name="myOtherObjectType" mixed="true">
   <xsd:complexContent>
     <xsd:restriction base="tmpType">
       <xsd:sequence>
         <xsd:element name="forwardingaddress" type="xsd:string"/>
       </xsd:sequence>
     </xsd:restriction>
   </xsd:complexContent>
</xsd:complexType>

Now you should be able to add the myOtherObject in the substitution 
group of myObject:

<xsd:element name="myOtherObject" type="myOtherObjectType" 
substitutionGroup="myObject"/>

Best Regards,
George
-----------------------------------------------
George Cristian Bina
<oXygen/> XML Editor & XSLT Editor/Debugger
www.---.com


Shane Lauf wrote:
> 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@s...>  
>>Subject: Re: Substitution groups - replacing required 
> 
> elements in the s.group head  
> 
>>To: Shane Lauf <srl01@u...>
>>Cc: xmlschema-dev@w...
>>
>>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
>>www.---.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
>>>
>>>
>>
> 
> 

From nobody@w...  Wed Aug  4 07:28:47 2004
Return-Path: <nobody@w...>
X-Original-To: xmlschema-dev+aa@l...
Delivered-To: xmlschema-dev+aa@l...
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.99])
	by frink.w3.org (Postfix)