LISTSERV mailing list manager LISTSERV 16.0

Help for EAD Archives


EAD Archives

EAD Archives


EAD@LISTSERV.LOC.GOV


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

EAD Home

EAD Home

EAD  April 1999

EAD April 1999

Subject:

Re: Entitites and XSL

From:

Alvin Pollock <[log in to unmask]>

Reply-To:

Encoded Archival Description List <[log in to unmask]>

Date:

Tue, 27 Apr 1999 11:40:42 -0700

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (59 lines)

>In the example above, we would encode the EAD link as
><extref href="myentity.sgm"/>

Michael, this has a profound impacy on how we interchange
our finding aids and use them in union databases. If you
are using <archref>, say, to link to another finding aid
you cannot assume your "myentity.sgm" is a unique filename
in a union environment simply because it's unique within
your own repository. In our Museums in the Online Archive
of California some of our members are using delivery software
which does not understand the redirection employed by the
entity mechanism. We've solved this problem by using both
an href attribute and an entityref attribute. Our union
server, Dynaweb, ignores the href attribute which it cannot
use in a union environment, and uses the entity mechanism
instead. The individual institution will use the href as
that's all its software can understand:

<extref href="myentity.sgm" entityref="myentity"/>

It's redundant information to be sure, but the fault is
not with SGML or XML, rather it's in that particular
software package. Interchange is the most fundamentally
important aspect of EAD and it's important not to compromise
this. I don't think everybody should use this duplicative
method, just those few repositories which are using delivery
software which is underpar.

Href is not a good attribute. There is no indication of the
*kind* of resource it's pointing to. If you are converting
to html for example, in one case you would be translating
to an <A HREF=""> tag for hyperlinks, and <IMG HREF=""> for
images, <APPLET> for still more complex resources. You face
the same problem in Panorama stylesheets. The conversion or
rendering software can only guess at what it should do. If
the software is sufficiently sophisticated, it could parse the
filename or url and make a decision based on the file
extension (Panorama cannot do this):

<extptr href="somefile.gif"/>  we can guess is an image
<extptr href="somefile.html"/> we can guess is a hyperlink

But how about more complex urls, such as this one taken from
an actual finding aid:

http://webpac.library.yale.edu/webpac-bin/wgbroker?new+-access+top.Yale_Lib+
search+open+ke+FHF5564

Href has a powerful attraction in that it is so familiar
to people used to dealing with HTML. The redirection employed
by entities is something people are not familiar with but
it's the *right* way to do this kind of thing in SGML and XML
and not for pedantic reasons only.

Alvin Pollock
Lead Programmer
Online Archive of California
http://sunsite2.berkeley.edu/oac

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In