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]