This question always seems to me to be one of those that one could answer,
if only we knew the future.
The problem of persistent web addresses is real and the limited
functionality within HTML for defining and managing various document types
is potentially problematic. As I see it, the problem is that there are no
clear solutions, only options. Entities flourished in the SGML environment
but are not so popular a solution within large segments of the XML and HTML
world. I sense that the exceptions are people who liked entities in the
SGML environment and want to replicate the functionality that they bring in
XML. Reasonable enough, except that a lot of other programmers have other
ideas as to the best solution and none of them have prevailed.
For example, many leaders in the XML world seem to dislike catalogs and look
to other solutions for persistent addressing. So there has been a resistant
to adding a lot of entity-related functionality within XML, such as
catalogs. That OASIS has had to do this as a separate project reflects the
division of opinion. The unparsed-entity-uri function was added to XSLT
late in the development of version 1.0 but falls far short of full support
for entities. For example, I am unaware of any standard way you can pass an
entity declaration from one file to another as part of an XSL
transformation, such as converting an EAD document from version 1.0 to
version 2002. Someone please tell me that this is not so.
In short, as Willie Nelson says, "there must be two sides to every story."
At least two and I don't know which one to believe.
From: Alvin Pollock [mailto:[log in to unmask]]
Sent: Thursday, February 26, 2004 12:10 PM
To: [log in to unmask]
Subject: Re: entityref verses href
I'll add another advantage to Richard's: with entities you also
have a NOTATION to tell you the type of resource being linked
to. NDATA JPEG, NDATA GIF tells your stylesheets that the
resource is an image and may be rendered in HTML with <img>.
NDATA METS might tell your stylesheet to render as <a>. NDATA
WAV might prompt your stylesheet to display information about
appropriate sound players. And so on. Encoding institutions
which are beginning to move beyond embedding just images may
find themselves wishing for some kind of type attribute, e.g.,
type="image", type="sound", type="tei document", etc. In those
cases they should really begin investigating entities instead.
Entities provide a very useful indirection mechanism. Your
actual hypertext links can be stored in a single XML Catalog
file. When URLs change there is no need to update hundreds
of EAD files. Simply change the catalog file entries or a
single rewriteSystem or rewriteURI entry. See:
We have found entities to be critical especially for creating
links to related EAD finding aids in <archref>. We completely avoid
hardcoding URLs to a particular presentation system du jour and
refer instead to the formal public identifier of the target
finding aid as encoded in its <eadid>. So as out presentation
or indexing system changes there's no need to worry about anything
encoded in our hundreds of finding aids. We simply alter the
single catalog file and everything automatically works.
People seem to prefer @href because they are familiar with it
from HTML. But they seem to forget all of the headaches associated
with broken links and changing URIs that continue to plague
As Richard points out, the Application Guidelines were written
in 1998. Many people do not realize that since that time XSLT
supports unparsed-entity-uri and other related functions for
obtaining information about entities.
Digital Publishing Group
UC Berkeley Library
>I think it's horses for courses, and very much depends on the nature of
>The advantage of the entityref approach is that a finding aid encoder
>can assert a link betwen *logical* entities without knowing about how
>the system is being implemented. In theory, URLs can be associated with
>the entities at runtime by whatever software (web server, XML editor...)
>is handling the delivery.
>As the 1998 Application Guidelines say, it is a "technically elegant"
>approach, that leaves the assignment of physical locations to separate
>catalogue files or other resource brokers. However, as they also say,
>> There are technical disadvantages to this approach. Web browsers that
>> support XML and the use of XSL or CSS stylesheets are unable to
>> access and resolve such entity names into explicit resource addresses
>> such as URLs. It would require specialized programming to create
>> workarounds for this problem. In addition, the overhead of supplying
>> a well-formed FPI (as specified by the ISO 9070 standard) for each
>> digital resource is not insignificant.
>On our NDAD system (http://ndad.ulcc.ac.uk/), we have stuck with href
>for the time being, since our internal references double as URLs (within
>our domain) - and everything is transformed into HTML anyway. If the
>tide were to change, it doesn't seem like it would be terribly difficult
>to harvest all the hrefs and substitute entityrefs.
>\ Richard M Davis
>/ Digital Archives
>\ University of London Computer Centre
>/ Tel: +44 (0) 20 7692 1350
>\ mailto: [log in to unmask]