XSD: restrict number of elements with certain attribute value

[Joshua Mostafa]

Hi there.

I have a question regarding restrictions in an XML Schema definition.

My XML contains a structure like this:

<fruit-bowl>
<fruit name="apple" />
<fruit name="pear" />
<fruit name="lychee" favourite="true" />
</fruit-bowl>

The problem is that it should be impossible to specify more than one
favourite. However, I don't know how to write this rule in XSD. I need
to restrict the number of elements *with a certain attribute value*.
Any ideas?

Everything else is there ... this is as far as I've got:

<xs:complexType name="FruitBowlType">
<xs:sequence>
<xs:element name="module" type="FruitType" minOccurs="1"
maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>

<xs:complexType name="FruitType">
<xs:attribute name="name" type="xs:string" use="required" />
<xs:attribute name="favourite" type="boolean" />
</xs:complexType>

[Joe Kesselman]

Joshua Mostafa wrote:

The problem is that it should be impossible to specify more than one
favourite.

XML Schemas doesn't express this kind of ... ahem ... co-dependency. I
would suggest you change your document structure to express the idea in
a way that schemas can handle. For example:

<fruit-bowl favourite="lychee">
<fruit name="apple" />
<fruit name="pear" />
<fruit name="lychee"/>
</fruit-bowl>

or

<fruit-bowl>
<favorite-fruit name="lychee"/>
<fruit name="apple"/>
<fruit name="pear" />
</fruit-bowl>

I think you can structure either of these to guarantee consistancy.

The only other solution I can think of is to define element types for
both fruit and favorite-fruit, structure the fruit-bowl so it can only
contain one favorite-fruit, then use the xsi:type directive to force one
of the fruit elements to actually be a favorite-fruit. But I think
xsi:type can only select among subclasses, which would mean a fruit with
that override would also be an instance of fruit, which would seem to
create a conflict in terms of how to interpret it... But that's well
outside what I've actually tried to do with schemas, so don't take my
word for it; find someone who knows, or try it and see if it fails.

However, I don't know how to write this rule in XSD. I need

to restrict the number of elements *with a certain attribute value*.
Any ideas?

Everything else is there ... this is as far as I've got:

<xs:complexType name="FruitBowlType">
<xs:sequence>
<xs:element name="module" type="FruitType" minOccurs="1"
maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>

<xs:complexType name="FruitType">
<xs:attribute name="name" type="xs:string" use="required" />
<xs:attribute name="favourite" type="boolean" />
</xs:complexType>

--
() ASCII Ribbon Campaign | Joe Kesselman
/\ Stamp out HTML e-mail! | System architexture and kinetic poetry

[Pavel Lepin]

Joshua Mostafa <mi*****@gmail.comwrote in
<11**********************@n59g2000hsh.googlegroups .com>:

I have a question regarding restrictions in an XML Schema
definition.

[...]

The problem is that it should be impossible to specify
more than one favourite. However, I don't know how to
write this rule in XSD. I need to restrict the number of
elements *with a certain attribute value*. Any ideas?

It seems to me that the XML community is coming to the
consensus that W3C's XML Schemata are only to be used for
checking the structural validity of XML documents, and not
for checking the logical validity. (Well, the XML Schema WG
members themselves were probably well-aware of what they
were doing ever since they started working on XML Schema
recommendations.)

I believe Joseph Kesselman recently quoted Dr. Chomsky as a
good example of what that means. I'll do the same:

<quote>

1. Colorless green ideas sleep furiously.
2. Furiously sleep ideas green colorless.

It is fair to assume that neither sentence (1) nor (2) (nor
indeed any part of these sentences) had ever occurred in an
English discourse. Hence, in any statistical model for
grammaticalness, these sentences will be ruled out on
identical grounds as equally "remote" from English. Yet
(1), though nonsensical, is grammatical, while (2) is not.

</quote>

Basically, XML Schemata are for weeding out (2)s, but not
(1)s. As the passage quoted indicates, the boundary between
the two is actually a bit fuzzy, and you may define
grammars that will make certain meanings outright invalid
(Joseph Kesselman's response to your posts contains
examples of those). As a result, if your documents are
highly structured, checking the structural validity will
catch many of the logical inconsistencies. If they're not
(as yours isn't), you'll have to explicitly check for
logical inconsistencies using some other means.

--
Pavel Lepin

[Joe Kesselman]

Pavel Lepin wrote:

It seems to me that the XML community is coming to the
consensus that W3C's XML Schemata are only to be used for
checking the structural validity of XML documents, and not
for checking the logical validity.

I wouldn't quite say "only" -- if your concepts of logical validity are
simple enough to be expressed by the schema, you're good to go, and
sometimes restructuring the document will permit you to achieve that
even for some moderately complex concepts.

But there will be many cases where schema can't do it all, though it
will simplify your life by doing much of it... and by helping you
explain at least some of the constraints to the users (and to generic
XML tools).

(Well, the XML Schema WG
members themselves were probably well-aware of what they
were doing ever since they started working on XML Schema
recommendations.)

I believe so. XML schemas were based in large part on database schemas,
which are also about structuring the data rather than checking its
meaning. The fully general checking problem needs a fully general
programming language, which isn't what XML Schema was designed to be.

There are other schema languages and validation frameworks for XML, such
as Relax-NG or Schematron, which can express things XML Schema can't.
The downside of using these, of course, is that since they aren't part
of the W3C's core standard set they're less likely to be supported by
any given set of tools and there are fewer people who are really fluent
in them. I haven't used them yet -- I haven't done anything that needed
complicated validation, and indeed many of the documents I work with are
minimally validated or simply well-formed -- but they're certainly worth
looking at as educational material, and may be worth considering if you
have enough control over your environment to count on their being available.
--
() ASCII Ribbon Campaign | Joe Kesselman
/\ Stamp out HTML e-mail! | System architexture and kinetic poetry

[Joshua Mostafa]

Thanks for all the enlightening responses! The linguistic analogy in
particular made the difference clear.

The favourite-fruit option seems to me to be the best solution; that
way I can demand at least one fruit. If I wanted to subclass, to avoid
redundancy in type definition, I could always subclass both fruit and
favourite-fruit from an abstract-fruit type.