Cart
[Home] [By Thread] [By Date] [Recent Entries]
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 ****************************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
