Putting xsd:any inside xsd:choice is not desirable.. the following schema ( copied for reference from below) would validate any content under x. It is as good as defining element x of type xsd:any with maxOccurs='unbounded" <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:element name="x"> <xsd:complexType> <xsd:choice maxOccurs='unbounded'> <!-- array of choice --> <xsd:element name="name"/> <xsd:element name="address"/> <xsd:any processContents="lax"/> </xsd:choice> </xsd:complexType> </xsd:element> </xsd:schema> If there are good practical uses case scenarios that we know for having xsd:any with maxOccurs > 1 inside sequence ( ordered or not) then we should allow it otherwise it just adds unnecessary complexity to the model, parsers, tools for a functionality that no one might require/use . . Suman Kalia IBM Toronto Lab WebSphere Business Integration Application Connectivity Tools Tel : 905-413-3923 T/L 969-3923 Fax : 905-413-4850 T/L 969-4850 Internet ID : kalia@ca.ibm.com Mike Beckerle <beckerle@us.ibm.com> Sent by: dfdl-wg-bounces@ogf.org 11/21/2007 01:44 PM To dfdl-wg@ogf.org cc Subject [DFDL-WG] DFDL wildcards with dimension I did some investigation. 1) xs:any wildcards are not allowed inside xs:all groups at all. 2) The schema below is valid, and admits the instance document following it: <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:element name="x"> <xsd:complexType> <xsd:sequence> <xsd:element name="name"/> <xsd:element name="address"/> <xsd:any processContents="lax" minOccurs='0' maxOccurs='unbounded'/> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema> Here's the instance: <?xml version="1.0"?> <x> <name/> <address/> <foo/> <bar/> <quux/> <frobboz/> </x> 3) Note however, the only way to create an XML Schema which will validate both the instance above and the one below where the order is all scrambled, is an array-of-choice schema: <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:element name="x"> <xsd:complexType> <xsd:choice maxOccurs='unbounded'> <!-- array of choice --> <xsd:element name="name"/> <xsd:element name="address"/> <xsd:any processContents="lax"/> </xsd:choice> </xsd:complexType> </xsd:element> </xsd:schema> This array-of-choice schema will accept this instance document also: <?xml version="1.0"?> <x> <foo/> <address/> <bar/> <name/> <quux/> <frobboz/> </x> The above array-of-choice schema obviously will also accept things where there are multiple name and address entries, which is undesirable, but the XPath expressions x/name and x/address will still work. <?xml version="1.0"?> <x> <address/> <address/> <foobar/> </x> Implications for DFDL: I suggest we should allow dimension on any wildcards because this unordered sequence DFDL fragment: <xsd:sequence dfdl:ordered="false"> <xsd:element name="name"/> <xsd:element name="address"/> <xsd:any id="unknown" processContents="lax" minOccurs='0' maxOccurs='unbounded'/> </xsd:sequence> describes something quite useful which otherwise requires an array of choice to model. Array-of-choice is generally undesirable as a model because it loses the cardinality information that says that name is required and address is required and there can be exactly 1 instance of each. ...mikeb Mike Beckerle STSM, Architect, Scalable Computing IBM Software Group Information Platform and Solutions Westborough, MA 01581 direct: voice and FAX 508-599-7148 assistant: Pam Riordan priordan@us.ibm.com 508-599-7046 -- dfdl-wg mailing list dfdl-wg@ogf.org http://www.ogf.org/mailman/listinfo/dfdl-wg