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.
If the main issue is conversion back and forth between DELTA and a more XMLish tree-based representation, or generating from a database, the complexity of such ID's is insignificant, because they are easily managed programattically. However, if people actually *like* a list-like format, and intend to markup XML by hand, then managing id's may be more of a nuisance.
Robert A. (Bob) Morris writes:
Date: Mon, 6 Nov 2000 11:49:40 -0500 From: "Robert A. (Bob) Morris" ram@cs.umb.edu To: TDWG-SDD@usobi.org Subject: Delta-like descriptions for Thiele 0.3 draft
III. Unique ID's (Non XML hackers please avert your eyes). We can not see where XML-Schema Schema syntactically enforces uniqueness of ID's. If this is so, ID uniqueness must either be ignored, enforced by context, or enforced by semantics at processing time. For example, in draft 0.3, several objects have id="1". The XPath function library is strong enough to use an ID as key when its uniqueness is given only by context as in Examples 8 and 9 in draft 0.3, but if we accept this approach, will we end up with a Schema against which validity testing is hard? OTOH, if we are wrong and XML-Schema Schema does enforce global uniqueness of ID, then must we uniqify the proposal by encoding the context in the ID itself? That seems fragile.