CODEWITHSUNDEEP
xmlxsdxsd-validationxml-validation
bvdb
bvdb

Reputation: 24710

all maxOccurs unbounded in XSD version 1.0

I have an XML structure that looks like this:

<node>
  <!-- node contains a lot of optional property nodes, 
       and the order is random. -->
  <property2>value</property2>
  <property1>value</property1>
  <property4>value</property4>
  <property3>value</property3>

  <!-- node also contains 0-to-unbounded child elements 
       to simplify things, these are listed after the properties. -->
  <child> ... </child>
  <child> ... </child>
  <child> ... </child>
</node>

I understand that in XSD 1.1 I can validate this as follows:

<xs:all>
  <xs:element name="property1" minOccurs="0"/>
  <xs:element name="property2" minOccurs="0"/>
  <xs:element name="property3" minOccurs="0"/>
  <xs:element name="property4" minOccurs="0"/>
  ...

  <xs:element name="child" minOccurs="0" maxOccurs="unbounded"/>
</xs:all>

Unfortunately, I should do this in XSD 1.0. (i.e. The consuming application does not support XSD 1.1.) However, XSD 1.0 does not allow maxOccurs="unbounded" restrictions for elements which defined in an xs:all node.

Not everything has to be validated strictly.

Upvotes: 1

Views: 890

Answers (1)

kjhughes
kjhughes

Reputation: 111511

If those properties have no substructure, consider making them attributes rather than elements; then you can have order insignificance.

Otherwise, state an ordering on the property elements and don't worry about it. Never have I seen an ordering impose an undue burden on an application generating XML data. Instead, it's always that an XSD designer sees no intrinsic need for ordering and fears imposing one arbitrarily. In reality, however, a sequence works fine unless the order of elements is itself being used to convey information. In all other cases, an XSD 1.0 xs:sequence will be fine.

Upvotes: 1

Related Questions