I haven't read the spec or commentary yet, but only looked at your example. It may be that the spec excludes this, but I would rather see a <STATEMENT> be allowed multiple <ELEMENT> elements thus:
<STATEMENT> <ITEM> <ITEM_NAME> Gouania exilis </ITEM NAME> </ITEM> <ELEMENT> <ELEMENT_NAME> Flower colour </ELEMENT_NAME> </ELEMENT> <VALUE> green </VALUE> <QUALIFIER> rarely </QUALIFIER>
<ELEMENT> <ELEMENT_NAME> Petal shape </ELEMENT_NAME> </ELEMENT> <VALUE> ovate </VALUE>
</STATEMENT>
Even more readable is the use of attributes
<STATEMENT> <ITEM name="Gouania exilis" /> <ELEMENT element_name="Flower colour" value="green" qualifier="rarely" /> <ELEMENT element_name="Petal shape" value="ovate" /> </STATEMENT>
In XML the difference between using attributes and using content as you did is usually a matter of style. There are some subtle and one not so subtle differences though: an attribute name must be unique in an XML element. You can't have <ELEMENT element_name="location" value="Costa Rica" value="New Zealand" />
so if you need two locations you have to use content
<ELEMENT element_name="location">Costa Rica</ELEMENT> <ELEMENT element_name="location">New Zealand</ELEMENT>
or else prescribe a list syntax, e.g. separator based <ELEMENT element_name="locations" value="Costa Rica | New Zealand" />
Yet more readable might be to make the element_name's value be the attribute, at least when the element_name is a traditional character: <STATEMENT> <ITEM name="Gouania exilis" /> <ELEMENT flower_colour="green" qualifier="rarely" /> <ELEMENT petal_shape="ovate" /> <ELEMENT locations="Costa Rica | New Zealand" /> <STATEMENT>
This can be somewhat simplified by putting all the characters as attribute on a single ELEMENT where reasonable.
Using a list syntax imposes parsing requirements (for the list) on the application beyond those that will be provided by an XML parser and the headache is probably not worth the parsimony obtained.
Bob Morris
participants (1)
-
Robert A. (Bob) Morris