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'> 
<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'> 
<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