from Kevin Thiele;
| Ah, Jun Wan reminds me that uniqueness of ID attribute values is | imposed by XML itself. So in the Delta-like descriptions, the choices | I see are to generate unique ID's that encode the context or to use a | different attribute than ID, perhaps something like TDWGID. In the | former case one might have something like: | ID="F.1" to mean that this is an id for feature 1 | ID="F.V.1.2" to mean that this is value 2 for feature 1 | In XSLT, these are parseable with the XPath string functions, so that | nothing more than XSLT is needed to associate an IDREF with the object | having the associated ID.
This is a nuisance. TDWGID I think is not a likely candidate.
Using your first option, one could use simply: ID="1" (id for feature 1) ID="1.2" (id for value 2 of feature 1)
This may then perhaps even be handy. Then again, by constraining like this it would quickly become a nightmare to add or re-arrange features or values.
Is this the first case where we're being imposed upon by XML and we start to wear the cost of its advantages? Are there any other ways out?
Rather than inserting 'ID' type elements within the XML, you could instead define xsl:key elements in a xsl stylesheet and then use the XPATH key() function to access the values. The key() function works in pretty much identical way as the XPATH id() function, but a key (unlike an id) doesn't need to be unique. don