[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xml-dev] Re: determining ID-ness in XML
- From: bob mcwhirter <firstname.lastname@example.org>
- To: email@example.com
- Date: Thu, 01 Nov 2001 22:41:06 -0500 (EST)
Granted, I haven't work with XPointer, but I am an XPath bigot, and
here's my thoughts (useless as they may be...)
Since currently ID's can only be attributes, they initially seem
orthogonal to the content model itself. The semantics of my document
fragment may make a particular element's text content the 'id' for my
intents and purposes. Call it a primary key, if you're relational.
ID attributes, in my mind, are (or should be) immutable, non-semantic
identifiers. Ayup, non-semantic. Shouldn't mean diddly to your
application. I think of them, typically, as LOIDs (Logical Object
ID, from the OODBMS world). Likewise, I feel they should be univerally
unique. Of course, that's quite difficult to acheive, unless we
head down a ID-URI-Prefix route, or similar, so that my object space
doesn't mix with your object space.
With aggregation of document fragments, and the restriction that
an ID should be unique within a document, the univerally-unique
property is even more important.
What does all of this mean, really? Beats me. Without having
application semantics attached to the ID attribute, it's difficult
to divine/predict what an element's ID will be. Might end up
with psuedo-random bits to identify each element. So, I'd say
use XPaths instead, and avoid the whole ID thing. But, as noted,
*certain* XPaths aren't stable, in light of assembling document
fragments, or through the normal course of editing. So, I guess
I'd have to qualify it as XPaths-Without-Proximity-Predicates
should be used as IDs. And that's what I tend to do.