- From: Jeni Tennison <jeni@jenitennison.com>
- Date: Mon, 25 Feb 2002 19:40:49 +0000
- To: Brenda Bell <bbell@juicesoftware.com>
- CC: "'xmlschema-dev@w3.org'" <xmlschema-dev@w3.org>
Hi Brenda,
> I actually found another option (perseverence is key :):
>
> <xs:group name="baseGroup">
> <xs:all>
> <xs:element name="A" type="xs:string" minOccurs="1"
> maxOccurs="1"/>
> <xs:element name="B" type="xs:string" minOccurs="1"
> maxOccurs="1"/>
> <xs:element name="C" type="xs:string" minOccurs="1"
> maxOccurs="1"/>
> </xs:all>
> </xs:group >
>
> <xs:complexType name="extendedType">
> <xs:sequence>
> <xs:group ref="tns:baseGroup"/>
> <xs:any namespace="##other" minOccurs="0"
> maxOccurs="unbounded" processContents="skip"/>
> </xs:sequence>
> </xs:complexType>
Hmm... I don't think that this is legal; I think that the only place
that you can refer to a model group definition whose model group is an
all group is directly from a complex type definition. Testing with
Xerces-C++ confirms this, though I can't put my finger on the place in
the Rec where it's stated.
Certainly, this ties in with the fact that you can't define an xs:all
directly within a xs:sequence -- model group definitions are supposed
to just give names to model groups so that you can reuse them, not
allow you to do things that you can't do otherwise.
Hopefully Henry or someone will be able to point to the relevant
constraint in the Rec...
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
Received on Monday, 25 February 2002 14:40:52 UTC