Re: [xsl] Identifier attribute (was: Re: [xsl] Creating Hierarchy)

Subject: Re: [xsl] Identifier attribute (was: Re: [xsl] Creating Hierarchy)
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Fri, 17 Oct 2008 13:06:20 -0400
Hi Ken,

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.)

Sure, but I was assuming since he said "ID attribute" and not "identifier attribute" that he was citing ID-ness for the value.

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.

In all of the XML vocabularies I've designed for clients, standards and myself the last few years I've been avoiding:


in favour of:



because of the implied semantics.

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. :-)


====================================================================== Wendell Piez mailto:wapiez@xxxxxxxxxxxxxxxx Mulberry Technologies, Inc. 17 West Jefferson Street Direct Phone: 301/315-9635 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ======================================================================

Current Thread