Re: [xml-dev] Conditional statements in DTD?

["C. M. Sperberg-McQueen" <cmsmcq@acm.org>]

On 11 Mar 2009, at 12:15 , Graeme Kidd wrote:

>
>
> Hi All,
>
> I am certain you cant use conditional statements within the DTD file  
> so is it possible to make an attribute valid only if a parent  
> element had an attribute set to something ...
>
> Surely things like this could be rather common?
>


The view taken in the design of DTDs is essentially that if one
element can legitimately have a 'playing' attribute and another
element cannot legitimately have a 'playing' attribute, then they
appear not to be of the same type.  So give them different names.
This view seems not so different, to me, from the database analysis
discipline that says if some Xs have attribute Y, and other Xs
do NOT have attribute Y, you should consider the possibility that
you are using the name X for two different kinds of thing, and
provide different names for the different kinds.

In practice, of course, people often want to do this even if
it's not always a good idea.  SQL allows columns to be declared
as allowing NULL (or not allowing it), and it allows row-level
CHECK clauses that permit the schema author to formulate rules
like "if ALLOW = 'no' then PLAYING IS NULL" or "if PLAYING IS NOT NULL
then ALLOW='yes' or ALLOW='maybe'".

Analogously, schema languages provide various ways of making
the type or validity rules for elements context-dependent.

Both XSD 1.0 and Relax NG, for example, allow the type (non-terminal)
of an element to depend on the context in which it appears.
Schematron allows the full expressive power of XPath expressions,
so you can say things like "the difference between @x and @y,
modulo 7, must be the same as the value of the @checksum attribute
on the fourth ancestor's second right sibling named 'fred',
unless @checksum = 'frazzgabble', in which case @x must
equal 2 * @y".  (Without extension functions, though, I don't
think Schematron can require that if @x is "yes", then @y
must be a prime number.)

RelaxNG also allows a degree of context-dependence based
on the value or type of various attributes; it works pretty
well as long as you can conveniently enumerate all cases.

XSD 1.1 adds both conditional type assignment and assertions,
either of which can be used to handle the case you have in mind.

But from the point of view of clean modeling, I think the question
posed by DTDs here remains salient:  if some of these StepTwo
elements are allowed to have 'playing' attributes, and some aren't,
then why are you calling them by the same name?  Would it not be
better to give them different names?

Having more expressive power is sometimes convenient, but a lot
of the value of XML lies in making it easier to process things
based just on the generic identifier (er, element type name) of
the element.  Whenever things get more complex, that complexity
gets passed along to every piece of software that has to process
the data.

So, to answer your question:  it's not that unusual for people to
have this kind of idea.  But it's possible to solve the problem
by designing the language differently, and the experience of
twenty years or so with descriptive markup have persuaded at least
some people that the alternative design is often better.
Your mileage, of course, may vary.

I hope this helps.

C. M. Sperberg-McQueen


-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com
* http://cmsmcq.com/mib
* http://balisage.net
****************************************************************