The eadid element obviously provides a method for specifying a
url of an xml file placed on a webserver.
However, many insitutions either do not want to provide direct
access to the xml file. By the same token direct access to an
xml file may be useful for information exchange, but loading an
xml file in your browser does not provide sytled text unless a
css or xslt is referenced--which is something few institutions
MY question: Is there a method using the elements and attributes
of EAD 2002 to specific the URN/URL or another persistent
identifier for the styled version of the xml file. I have been
unable to find anything, although I may be missing something
Given the difficulty in writing stylesheets that can capably
style finding aids written by disparte insitutions, it seems
logical that there by some way for aggregators to provide direct
access to the publisher's public version of the finding aid.
Christopher J. Prom
Assistant University Archivist
University of Illinois at Urbana Champaign
1408 W. Gregory Dr.
Urbana, IL 61821
e-mail: [log in to unmask]
On Tue, 18 May 2004, Fox, Michael wrote:
> Dear Yann,
> With respect to the integration question you raise in point two, you are
> correct at one level but I believe that there is another way to look at this
> issue. Library ILS software is vertically integrated but only within a
> particular vendor application. The turnkey aspect of such systems seems the
> most convenient solution for the staff user who needs a complete toolkit to
> perform a range of functions. But as someone who has moved MARC data
> between a number of utilities and local systems, this has been mixed
> blessing in three respects.
> 1. Sometimes the vendor does not provide all of the components of the
> system and we have to patch in another solution to get needed functionality.
> Suddenly, the operation is no longer seamless.
> 2. The tools the vendor provides are not "best of breed' and you find
> yourself stuck with a serials control or media booking or some other
> subsystem that has less than optimal functionality. The selection process
> of ILS software is often a matter of compromise in selecting the feature set
> that most closely, but seldom in all ways, meets ones requirements.
> 3. Vendors implement solutions that are not standards-based or that are
> not able to reflect standards upon data output. This can leave you in a
> bind when you want to share data or migrate to a new application. My
> colleagues have many stories to share on this subject during our recent
> implementation of a new ILS.
> The lack of full vertical integration that you see in EAD is, in fact, the
> norm in web delivery of information. HTML editors, database software, and
> web servers all must be synchronized, even if the details of that process
> are hidden from the various participants in the operation. Most
> applications seem to require the bolting of some, if not all, of the
> components together. This approach lets you employ the best and most
> standardized solution for each part. One trades control for a certain level
> of complexity.
> -----Original Message-----
> From: Yann Nicolas [mailto:[log in to unmask]]
> Sent: Monday, May 17, 2004 5:55 AM
> To: [log in to unmask]
> Subject: Tools for EAD
> Recently, messages concerning XML editors and EAD have been posted to this
> As I read them, two questions stroke me :
> 1. It is clear that several tools are available to create EAD inventories,
> but all of them are generic XML editors, not specific EAD editors. At best,
> you can use specific EAD stylesheets to feed and adapt your generic XML
> editor. You can also use the .dtd or an .xsd (W3C XML schema) in the same
> But is there any specific EAD XML tool ? If the answer is no, why ? Are
> generic tools sufficient ?
> 2. It seems that the various tasks concerning EAD instances (creation,
> indexing, display, search) are not made by integrated tools, but by
> different generic tools that are thereafter more or less integrated by each
> local EAD producer. It strongly contrasts with Integrated Library System.
> It seems that this "scattered" configuration makes difficult such actions as
> - updating (if you change just a minor part of your finding aid, you have to
> treat it as a whole : changing a part in your editing tool, but charging the
> whole in your indexing tool)
> Maybe my concerns come from some hidden (or patent ?) librarian's bias.
> Finding aids have definitively not the same needs as bibliographic records :
> not the same structure, size, rythm of creation and updating, not the same
> necessity of data exchanges between instituition....
> Nevertheless, the "regular" life cycle of EAD intances seems unstable and
> non integrated. Isn't it an obstacle to a larger adoption of EAD ?
> Merci de votre attention et à bientôt,
> Yann NICOLAS
> ABES - Agence Bibliographique de l'Enseignement Supérieur
> Service : Produits et Services
> Dossiers : Portail Sudoc, Thèses électroniques, CGM
> 04 67 54 84 25
> mailto:[log in to unmask] <mailto:[log in to unmask]>