XSD: Order irrelevant but choice required
Stephan Mann
I'm relatively new to XSD but I did not think that my requirement would
prove to be such a problem. But after two hours of trying and searching
I'm now thoroughly confused. Maybe someone could point me into the right
direction.
Requirement: There are three elements. One is optional, while the other
two are exclusively to each other. One of the latter might appear
multiple times.
Therefore, I wrote the following XSD, which is working perfectly:
<xs:element name="Root">
<xs:complexType>
<xs:sequence>
<xs:choice>
<xs:element name="One" type="xs:string" maxOccurs="unbounded" />
<xs:element name="Two" type="xs:string" />
</xs:choice>
<xs:element name="Description" type="xs:string" minOccurs="0" />
</xs:sequence>
</xs:complexType>
</xs:element>
It allows <One> multiple times OR <Two> once and <Description> is
optional. The problem I can't get my head around is how to achieve that
the order of the choice group and the description tag is irrelevant.
<Description> should be allowed to occur first.
All my attempts to do that have failed. I'm not allowed to use <all>
instead of <sequence>, because <all> is only allowed to contain
elements. And if I replace the <sequence> with an
<xs:choice maxOccurs="unbounded">
the order is no longer relevant, but also an *empty* XML document is now
valid (which had me surprised for a moment, but I think I understand it
now).
I'm completely in the dark on how to achieve my additional requirement.
Specifying all possible permutations in a choice of sequences is
obviously no solution, since I need a lot more elements in the final
XSD. It seems simple to me but I can't get it to work, so any help would
be greatly appreciated.
tia, stephan
C. M. Sperberg-McQueen
> Hi,
>
> I'm relatively new to XSD but I did not think that my requirement
> would prove to be such a problem. But after two hours of trying and
> searching I'm now thoroughly confused. Maybe someone could point me
> into the right direction.
>
> Requirement: There are three elements. One is optional, while the
> other two are exclusively to each other. One of the latter might
> appear multiple times.
>
> Therefore, I wrote the following XSD, which is working perfectly:
> ...
And which meets the requirements you've given.
> It allows <One> multiple times OR <Two> once and <Description> is
> optional. The problem I can't get my head around is how to achieve
> that the order of the choice group and the description tag is
> irrelevant. <Description> should be allowed to occur first.
Note that that is not mentioned in your description of your
requirements. Is it really a requirement?
> ...
> I'm completely in the dark on how to achieve my additional
> requirement. Specifying all possible permutations in a choice of
> sequences is obviously no solution,
Hmm. It's not obvious to me that it's not a solution. It
is in fact the only way I know of to specify the set of sequences
you seem to be looking for.
But I agree that it does tend to be tedious to express by hand.
> since I need a lot more elements
> in the final XSD. It seems simple to me but I can't get it to work, so
> any help would be greatly appreciated.
I can think of several lines of attack on the problem.
(1) Add an optional leading Description to your existing sequence
definition, and use application-level logic to check that you get
Description only at the beginning, or only at the end.
(2) Use XSD 1.1, use an all-group of One*, Two?, and Description,
and use an assertion to check that one or the other of One and Two appears.
(3) Question your analysis.
What information is conveyed by placing Description at the beginning
or at the end?
If the choice of position conveys some information, consider
representing it explicitly; that may well change the shape of your
documents.
If the choice of position conveys no information (which I suspect
is the case, since you say the order is "irrelevant"), why allow
it to vary? Why not simply require it always to appear last?
If the relative position of Description and One or Two conveys no
information, then it need not be allowed to vary. A content
model that fixes the sequence is much easier to manage, for such
simple cases, than one that allows the order to be different.
Is it really a requirement that your schema allow what amounts to a
covert channel for the export of undocumented information?
hth
--
Michael Sperberg-McQueen
Black Mesa Technologies LLC
Joe Kesselman
> covert channel for the export of undocumented information?
Well phrased, Michael. Mind if I archive that answer for possible
re-quoting in the future?
Sandard reminder: Schema isn't intended to do everything possible to
check your document. Sometimes the simplest answer really is to leave
the schema a bit looser than would be ideal and have application code
impose the additional constraints.