Re: [xsl] id() doesn't work!?

Subject: Re: [xsl] id() doesn't work!?
From: "W. Eliot Kimber" <eliot@xxxxxxxxxx>
Date: Sun, 25 Aug 2002 12:16:56 -0500
Aaron Optimizer Digulla wrote:

> Not having used xpointer to date, I don't know of the implications of it
> and how hard it would be to solve the warning problem (maybe id() can
> "throw an exception" somehow and xpointer() can discard it while the
> normal use would display it or somesuch - I would have to look at the
> sources to say that) but my guess is that it would be a simple thing
> for you to do.

When we were formulating XML, there was a lot of discussion of whether
we should codify "id" and "idref" as the attributes for ids and
references to them--the argument for was that it would avoid exactly the
problem that we see with the id() function (and, by extension, bare
names interpreted by the XPointer rules). The argument against was that
it intruded on the document author's name space, a cardinal sin. I
honestly don't remember which way I voted, but I probably voted against
codifying "id" because I was, at the time, firmly steeped in the
sanctity of the author's right to name.

In hindsight, I think it was a mistake not to have codified "id" and
"idref". The effect of the wide non-use of DTDs is that you are pretty
much forced to either use "id" as the name of your ID attributes and use
the "//*[@id='$name']" form of XPath or you must build into your style
sheets complete knowledge of the identifying name spaces used for
addressing.

At the end of the day identification and referencing are
application-level issues. A strong argument can be made that SGML should
have never defined an ID mechanism at all--there are too many
requirements it didn't meet and it only makes parsing and validation
harder. [How many of you old SGML hands out there worked with or
designed systems that defined all the ID attributes as "NAME" or "CDATA"
because the business rules required repository-wide IDs or scoped ID
uniqueness below the document level or need to solve the cross-document
addressing requirements that SGML alone didn't satisfy?]

If the Web has taught us anything it's that a few well-choosen and
ubiquitous naming conventions can take you a long way. While I still
believe strongly in the author's right to name, I no longer believe it
is a right that outweighs all other considerations. I think that the
problems raised by the ID attribute are a case in point--how much poorer
would we be if "id" only and always meant "id" if it meant that the id()
function always worked as expected?

I have recently gone through similar but distinct exercises:
implementing the XTM mergeMap element (in a Java processor
[http://www.isogen.com/downloads]) and implementing
as-complete-as-possible XPointer support using XSLT and EXSLT extensions
[http://www.dpawson.co.uk/xsl/sect2/xpointer.html]. In the first case I
map bare names in XPointers to "//*[@id='$name']" because the XTM spec
defines the name of the ID attribute as "id", so users of my mergeMap
resolver would expect bare names to *always* work, even though a strict
implementation of XPointer would have them fail when there is no DTD
(because bare names in XPointer map to id(), not //*[@id='$name']).
Most, if not all, of the sample topic maps I've seen use bare names for
in-document references, even when those documents do not have
IDs--technically those documents should fail because XTM specifies
XPointer and bare-name XPointers map to id(). But it would be what I
call "Simon says" behavior to not go ahead and do what all the authors
of those topic maps expect [If my mergeMap resolver refused to resolve
bare names in the absence of a DTD it would be essentially saying "I
didn't resolve those links because you didn't say 'Simon Says'--an
unpardonable implementation sin in my book.]

However, in my XPointer implementation, I cannot provide that natural
fallback behavior. That means that lots of authors will have to rewrite
their pointers from bare names to "//*[@id='name']" in order to make
their documents work--that seems wrong and avoidable to me.

But at the same time, the XPointer spec had little choice: it would be
wrong for that spec to impose the name "id" on users (XML could do it
because it's defining the markup language and individual document types
can do it, but an after-the-fact support mechanism like XPointer cannot)
and codifying even a standard fallback behavior would potentially lead
to subtle, non-intuitive failures (or lack of failure when failure is
expected) when 'id' was not in fact an ID attribute in a particular
document.

I think that the only answer to this problem is for the community of XML
users to agree on a convention for IDs and pointers and for it to be
codified in XML 2.0 or some such. I would be perfectly happy if "id"
always meant "ID" and "href" always meant "URI-based pointer". I think
the long-term benefit would far outweigh any cost in constrained naming
choices. There will always be specifications like HyTime that provide
for complete renaming of everything if you need to step up to that level
of flexibilty. I think the current situation represents the worst
compromise between ease of use and generality--it doesn't help in the
case where you need a simple, consistent solution that is guaranteed to
always work and it doesn't provide the flexibility you need because the
cost of using it (requiring DTDs with instances) is too high. 

XLink exacerbates the problem by fixing the names of the referencing
attributes (xlink:href), eliminating choice that might be useful in some
cases (for example, in transparently mapping XHTML attributes to XLink
semantics). I understand why the XLink committee was hesitant or
unwilling to step up to a more general name mapping scheme--it leads to
quite a bit of unavoidable complexity, but there are use cases for which
it is the only viable solution. [And I remind this audience that the
HyTime standard, ISO/IEC 10744:1997, still exists as one solution to the
requirement to be able to do unconstrained name remapping if you need
it--nobody buys a Swatch Car to haul furniture, but nobody buys a moving
truck to commute day-to-day either.]

Cheers,

E.
-- 
W. Eliot Kimber, eliot@xxxxxxxxxx
Consultant, ISOGEN International

1016 La Posada Dr., Suite 240
Austin, TX  78752 Phone: 512.656.4139

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread