From Mike...
In DELTA, character values in a description can't be separated from the 'attribute' which contains them, without losing information. This is because the order of the values, and the words 'or', 'and', and 'to' which may connect them, are significant. Also, the position of a qualifier (before or after a value) may be significant, and some qualifiers, e.g. 'reliability', may apply to the attribute as a whole rather than to a particular value.
Example:
5,3/3&1<when infected with virus>/<occasionally>2<@reliability 3>
= Flowers red, or red and white (when infected with virus), or occasionally yellow.
This doesn't seem to be accommodated in the proposal - at least, it's not spelled out.
Courple of things:
1. This raises one of the problems of DELTA as pointed out by Gregor and others at the TDWG meeting,which is that <comments> are being overloaded with meaning. There are various types of things here that are masquerading as being similar, when they're not at all.
* "<when infected by a virus>" is perhaps a true comment. In the above example, could this perhaps be covered by content?
<DESCRIPTION Name = "a taxon or thing"> <ELEMENT> Name = "Flower colour"> <VALUE> red <QUALIFIER> rarely </QUALIFER> </VALUE> when infected by a virus </ELEMENT> </DESCRIPTION>
Note that these comments are only used for natural-language descriptions (they're stripped out when DELTA translates to an interactive key etc). I don't see why the ordering of these true comments can't be accomodated by their position in the content with respect to the tags - since these are "trivial" comments in most contexts, this doesn't seem weak to me.
* <occasionally> is a qualifier as defined in the draft spec (only I'm calling it "rarely" in line with Lucid's terminology). Lucid is currently the only program that uses this type of qualifier in identification, and it's very important. But it's not to be confused with the common-or-garden variety of comment as above.
* <@reliability 3> is a command for a program. This should be made clear by the tag so that other programs can ignore it.
2. &. I've always been bothered by the use of & (and) vs / (or) in DELTA. Using Mike's example:
5,3/3&1 = "Flowers red, or red and white"
The use of & is handy for codifying natural-language descriptions, but in other applications it's highly problematical. This is a homology problem and has been discussed at length in the cladistic literature e.g.
*CHARACTERS #1. Dorsolateral appendages/ 1. arms/ 2. wings/
*ITEMS #Humans 1,1 #Birds 1,2 #Angels 1,1&2
The discovery of angels (having both arms and wings) would prove the non-homology of arms~wings, so the character as stated is false and should be restated "Arms present/absent" "Wings present/absent".
Similarly, in Mike's example, the red&white broken colouring of virus-infected tulips is actually non-homologous with uniform red or uniform white and should be a separate character (or at least a separate state).
So pending further discussion (which I'm sure will come) I propose that the standard should not support the & coding of DELTA.
Over to you, Mike... :-)
Cheers - k