I think consideration of this issue should be taken up in the next (though
not schedule) revision of EAD.
At 05:23 PM 8/9/2004, you wrote:
>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
> > 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
> > 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
> > of complexity.
> > Michael
> > -----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
> > Bonjour,
> > Recently, messages concerning XML editors and EAD have been posted to this
> > list.
> > 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
> > way.
> > 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
> > _____
> > 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]>