Cart
[Home] [By Thread] [By Date] [Recent Entries]
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. Anyhow... -bob
|
