1. Present editors seem sufficient for this task. I am not sure I
would agree that we need strictly XML editors. I still use my text
editor. All my myltibyte characters are escaped out (base 10 NCR). If
I need a character that is multibyte, I type in the NCR (in windows
you can use the character map to find the hex number). A nice java
table is available for viewing on the unicode site:
Frankly, I think that reducing all data to pure ascii (0020-007E ; a
subset of UTF-8), is the best method for doing any coding work. What
you see is what you get.
2. The difficulty as I see it, is the need to datatype the
information that is being coded. Some have approached this by
outputing from databases. Personally, I capture the MARC record, turn
it into XML, and then generate the front matter of the EAD document.
The generation using XSL & SAXON, has a look up document
associated with it to grab all the user data (scopecontent ; bioghist
My conclusion to much of the difficulty of updating and editing the
finished EAD document was to strip the coding away from the datatype
(MARC). I generate my EAD from XML master documents encoded with a
tag set based on MARC field and subfield values.
Library of Congress
--- Yann Nicolas <[log in to unmask]> wrote:
> 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 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]
Do you Yahoo!?
SBC Yahoo! - Internet access at a great low price.