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:
id=
in favour of:
xml:id=
ref: http://www.w3.org/TR/2005/REC-xml-id-20050909/
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. :-)
Cheers,
Wendell
======================================================================
Wendell Piez mailto:wapiez@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc. http://www.mulberrytech.com
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
======================================================================