How to *not* specify the order of occurrence?

[Stephan Mann]

Hi,

I want to give this one more try before I accept that this can't be
done. I did ask for this two weeks ago in this group[1] but did not
receive any answers, so I'm trying to rephrase my question.

I'm trying to remove the (inherent?) specification of the order of
occurrence from my XML schema. The goal is to allow elements to occur in
any order but still be able to set elements required or optional.

A "solution" I have found countless times in multiple variations while
searching for a way to do this is the use of a <choice>:

<xsd:element name="Root">
<xsd:complexType>
<xsd:group ref="group" maxOccurs="unbounded" />
</xsd:complexType>
</xsd:element>

<xsd:group name="group">
<xsd:choice>
<xsd:element name="Element1" minOccurs="0" maxOccurs="1" />
<xsd:element name="Element2" minOccurs="0" />
</xsd:choice>
</xsd:group>

On a first glance, this does what I want: Elements can be provided in
any order. But the side effects are severe! The attributes minOccurs and
maxOccurs are no longer in effect and - what's worse - even empty Root
tags are now valid.

This clearly makes any validation meaningless so it is no solution at
all. It seems to me that I'm ignorant of some basic concept or just
plain stupid, but in either case I would like to know/understand.

So again, could somebody provide me with some kind of hint regarding
this point? I settle for a link to the part of the XMLSchema spec where
it states, that this is not intended to be possible or for some other
group or mailing list I could trouble with this problem.

tia, stephan


[1]
http://groups.google.com/group/comp.text.xml/browse_thread/thread/dab30367a6ee5f9c#

 

[Peter Flynn]

Hi,

I want to give this one more try before I accept that this can't be
done. I did ask for this two weeks ago in this group[1] but did not
receive any answers, so I'm trying to rephrase my question.

I'm trying to remove the (inherent?) specification of the order of
occurrence from my XML schema. The goal is to allow elements to occur in
any order but still be able to set elements required or optional.

This feature of SGML was removed from XML (the "and" connector, at
production [131] of ISO 8879).

I believe it is possible to specify an equivalent constraint in schemas
but as I haven't had to use the requirement for at least a decade I've
never had to go and find out how. RNG is probably your best bet.

///Peter

 

[Joe Kesselman]

The goal is to allow elements to occur

in any order but still be able to set elements required or optional.

Unless you want to spell out all the possible permutations, I believe
the answer is that the W3C XML Schema language can't express that. Some
of the alternative schema languages that have been proposed do support
this kind of constraint, but of course those are not as well known or as
widely supported.

Note: Schemas were never intended to express *all* the semantic
constraints upon a document. They're just an initial filter. You should
expect that some aspects of the document's content will continue to be
checked/enforced by application code, either at the source or when the
document is consumed. (Or both.)

 

[Stephan Mann]

I'm trying to remove the (inherent?) specification of the order of
occurrence from my XML schema. The goal is to allow elements to occur
in any order but still be able to set elements required or optional.

This feature of SGML was removed from XML (the "and" connector, at
production [131] of ISO 8879).

I believe it is possible to specify an equivalent constraint in schemas
but as I haven't had to use the requirement for at least a decade I've
never had to go and find out how. RNG is probably your best bet.

Thank you so much for your reply. I was completely unaware of the
existence of other schema languages such as RNG or Schematron. However,
given the nature of the project and this specific request, switching to
another schema language is not reasonable at this time. But at least I
can now postpone the request with confidence and a proper reasoning.

thanks again,
stephan

 

[Stephan Mann]

Unless you want to spell out all the possible permutations, I believe
the answer is that the W3C XML Schema language can't express that. Some
of the alternative schema languages that have been proposed do support
this kind of constraint, but of course those are not as well known or as
widely supported.

I was considering to spell out all permutations until I realized, that
the model in which this problem occurs has no upper bounds for the
number of elements, which results in infinite permutations.

Switching to another schema language is not reasonable for this project
at the moment, since there are many things to consider besides simply
converting the schema files (libraries, editor support, ...) and there
is - as always - no time.

Note: Schemas were never intended to express *all* the semantic
constraints upon a document. They're just an initial filter. You should
expect that some aspects of the document's content will continue to be
checked/enforced by application code, either at the source or when the
document is consumed. (Or both.)

I'm not trying to validate semantics with my schema. The order of the
elements is IMHO a purely syntactical issue, since it carries no meaning
(at least in my model). Yes, I also need a semantic validator, but if I
would use the example from my original post, I would also have to do
syntax validation which is, IMHO clearly, the job of the schema.

thank you very much for your reply,
stephan

 

[Joe Kesselman]

I'm not trying to validate semantics with my schema. The order of the
elements is IMHO a purely syntactical issue, since it carries no meaning
(at least in my model).

Asserting the frequency of elements (ie, making some of them required)
is arguably starting to cross over from syntax into semantics. Yes, the
line between these two is unavoidably fuzzy...

If you're willing to give that up enforcing that constraint in the
schema, of course, the solution becomes much easier: A choice of all the
possible elements, repeated as necessary.

 

[Joe Kesselman]

The other solution is to enforce ordering, even though you don't think
it should matter... at least for the required elements.

 

[Stephan Mann]

Asserting the frequency of elements (ie, making some of them required)
is arguably starting to cross over from syntax into semantics. Yes, the
line between these two is unavoidably fuzzy...

If you're willing to give that up enforcing that constraint in the
schema, of course, the solution becomes much easier: A choice of all the
possible elements, repeated as necessary.

You certainly have a point here. I will give this some more thought.
Perhaps changing my attitude towards this problem is the easiest
solution after all. Again, thank you very much for your input!

stephan

 

[Joe Kesselman]

But if the OP's description of the goal is correct (allow any
order, and mark elements required or optional) and the example
is characteristic (none of the elements in question appears more
than once), the xsd:all can do what appears to be required.

Hmmm. You're certainly an authority on the topic... but I'm confused by
why I didn't notice this before. I need to re-read that, clearly. Thanks.

> (If the order has no significance,
there is really very little reason to allow the order to vary.
Variable but meaningless ordering is also a method of
steganography, which may worry some security people.)

Agreed. But sometimes convincing the customer that laziness is not
sufficient justification for allowing reordering can be difficult. And
there are other steganography opportunities in XML unless you spend the
cycles to normalize it. (Admittedly, element order is one that would
survive canonicalization.)