Schema: express that "@a present if and only if @b present", where @a, @b are attributes

[Ralf Wahner]

Dear Masters of XML

As I'm new to XML Schema I dare to ask a possibly recurring
question: Given an element <elem> with two attributes @a and
@b. The attributes are bound by the condition, that either both
or none must be present, i.e.

<elem a="val_a" b="val_b"/> or <elem/>

is valid, whilst

<elem a="val_a"/> or <elem b="val_b"/>

is not valid. In other words, attribute @a is present if and
only if attribute @b is present. How to express this be means
of XML Schema?

Could I ask you for a hint? Is there an insider's tip concerning
XML Schema comparable to the Mulberry Biglist on XSLT? Thank you
very much.

Yours sincerely,

Ralf

 

[Jesper Zedlitz]

As I'm new to XML Schema I dare to ask a possibly recurring

question: Given an element <elem> with two attributes @a and
@b. The attributes are bound by the condition, that either both
or none must be present,

That is not possible with W3C's xml schema.

Jesper

 

[Bob Foster]

That is not possible with W3C's xml schema.

But it is trivial to do in RELAX NG.

Bob Foster
http://xmlbuddy.com/

 

[Ralf Wahner]

Hallo Jesper and Bob

Thanks for you hints. I'll take a close look on
Relax NG. Isn't it astonishing that a task as
simple as this can't be mapped be means of XML
Schema?

Best regards,

Ralf Wahner

 

[C. M. Sperberg-McQueen]

Hallo Jesper and Bob

Thanks for you hints. I'll take a close look on
Relax NG. Isn't it astonishing that a task as
simple as this can't be mapped be means of XML
Schema?

I guess XML Schema takes the database notion of attributes
more seriously than some vocabulary designers. One
characteristic of a design in which this kind of
co-constraint occurs is that the design is apparently
trying to write two different kinds of objects using
the same element type. Where I come from, it's often
regarded as a sign of weakness in the design.

But your mileage may vary.

-C. M. Sperberg-McQueen
World Wide Web Consortium

 

[Bob Foster]

I guess XML Schema takes the database notion of attributes
more seriously than some vocabulary designers. One
characteristic of a design in which this kind of
co-constraint occurs is that the design is apparently
trying to write two different kinds of objects using
the same element type. Where I come from, it's often
regarded as a sign of weakness in the design.

But your mileage may vary.

My mileage varies so much on this point my odometer is spinning in both
directions! ;-}

On the one hand, the markup idiom where the presence or contents of an
attribute determines the remaining attributes and contents of an element is
very widely used. I can find dozens of use cases, but perhaps none would be
more convincing in this context but XML Schema, itself. To give just one
example, if an <element> element has a name attribute, it may have a type
attribute and/or type contents, but if it has a ref attribute it may have
neither. But XML Schema, the language, can't describe such a constraint.

On the other, I am always interested in improving my data analysis skills.
In the Eclipse IDE, for example, plug-ins are allowed to define arbitrary
extension points to which other plug-ins can connect and add capability. The
XML syntax for this is <extension point="name_of_extension_point"... The
remaining attributes and element contents are determined by the extension
points, which have widely varying and unpredictable requirements for
information from their extensions. How would someone who "takes the database
notion of attributes more seriously" have designed this?

(The designers of Eclipse might have appreciated this answer, as they, some
would say unwisely, chose to use XML Schema, which is incapable of modeling
the central construct of their plug-in manifest languge.)

Bob Foster
http://xmlbuddy.com/