Cart
|
[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Identifier attribute (was: Re: Creating Hie
 At 12:07 PM 10/17/2008, you wrote: Of course, the OP hasn't actually said his attributes named "id" need to validate as type ID. (Not that this isn't good advice in general, in case one ever wanted to do that.) I saw the glass as half-empty and assumed that since he didn't say "of type ID" in the schema sense, he might not have meant it.... But this brings up another issue we might have brought to the attention of the OP: the name of the attribute. Heh. While not against xml:id, I tend to avoid it for the same reason as you use it. :-) Often I find that the exact semantics of xml:id are not what's meant, particularly not through the life cycle throughout the documents in which a value moves (as documents are merged and split, etc.). The issue is scoping -- frequently the scope of uniqueness doesn't actually have to be as wide as the current document. Even more of an issue is when the identifier's uniqueness has to be broader than the current document, and one ends up having to overload the stated (standard) semantics of xml:id in order to give it the traction it needs. Accordingly, I think I'm happier with xml:id within specific application layers (such as a presentation language or wherever) when it actually fits. It could well be that the standard vocabularies you've worked with fit this description, in which case I'd be less likely to suspect there'd ever be a problem. Similarly, when offering advice I tend not to recommend the principle of "use the standard because it's a standard" as a counterweight to "implement constraints that fit the problem" and "avoid misleading names", both of which are more important in my book. To bring this back on topic, part of the reason for that is that XSLT gives us an easy way to map ID-valid values to xml:id when we need to -- in that, I suppose I'm a proponent of "late binding". I haven't run into any hiccoughs in any way by doing so ... has anyone run into roadblocks or unintended consequences doing the same? I dare say the unintended consequences would be less likely to be in processing per se, so much as in potential mismatches between expectations (of users and tools, etc.) in emergent circumstances. So, quite subtle. See, part of the (backward) advantage of a private language is that you have to keep explaining it to yourself and others. This can be expensive, but you are less likely to fall into the trap of thinking you mean the same thing as someone else, when you actually don't. Which can be expensive too, and quite hard to detect and fix. :-) Cheers, Wendell
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
