Mike:

some comments embedded below.

At 04:40 PM 9/5/2002 -0400, you wrote:
>Hello all,
>
>After a brief project hiatus, I've returned to the work of implementing EAD
>here at the Mass. Historical Society.  Looking with fresh eyes at the
>encoding template I created earlier, I have some questions:
>
>1.  I'm hunting for ways to reduce redundancy.  Encoding a series list in
><organization> seems superfluous when they are repeated in the <dsc> and can
>be extracted for display in a list.  Are there any compelling reasons to
>continue to encode the series list in <organization>?
>
>2.  Also in an effort to reduce redundancy, I'm considering not using
><frontmatter>.  The only piece of data which I had included in <frontmatter>
>which is not encoded elsewhere is publication copyright info for guides we
>actually published years ago, mostly to accompany microfilm editions.  If
>eadheader/publicationstmt refers to the electronic publication of a guide, I
>see no where else to encode it.  Does anyone else face the problem of
>encoding two separate sets of publication data, one for a printed version of
>a guide and one for the electronic version?  If so, have you managed to do
>it without using <frontmatter>?

I think, at base, that you are addressing a fundamental issues associated with markup: viz. to what extent is it necessary or desirable in an easy-to-manipulate-XML world to include presentational cues such as the label attribute, <frontmatter> (if, indeed, this is considered presentational), line breaks or tabulation? Without them I have less of a chance of being able to render your finding aid in the way you had intended, that is without _also_ looking at the logic of your transformative processes. This question of where the line is drawn between procedural and descriptive markup is an old one, but it seems to have been thrown into greater focus with the coming of XSLT.

One might also add that depending on the manner in which you actually produce your EAD, avoidance of "redundant" elements may lead in strange directions: the values for your <controlaccess> elements that map to MARC 600, for example, could very well generated from certain <persname>s. One needs by necessity to be _very_ careful in reduction and reconstitution at this level.


>3.  I plan on using the normal attribute for date and unitdate tags.  When
>encoding a date that has a missing date month or year, is the best practice
>to replace those digits with zeros?  For example, would you encode September
>2002 as normal="20020900" or September 5, no year, as normal="00000905"?

In ISO 8601, your examples would be:
200209 and --0905 (the hyphen is also an accepted field delimiter)

IIRC, the standard is mute on levels of uncertainty.



>4.  Does it make sense to encode collection dates as listed in the
>eadheader/titlestmt/titleproper in <date> tags?  In a moment of enthusiasm
>for lots of <date> tags I thought it would be a good idea, but now I'm less
>enthused and it seems pointless, especially since the same data is more
>explicitly identified in the archdesc/did/unitdate elements.
>
>5.  How do you recommend using the <eadid>?  I know lots of institutions use
>the SGML Open Catalog specification, but I'm unclear on how it works what
>the benefits are, and if it works in XML at all.  We don't anticipate
>sharing our EAD files in any sort of consortium at the moment, so I was
>planning on using a simple four-digit file numbering system.
><eadid systemid="MHS" type="file" encodinganalog="identifier">0001</eadid>
>(in which case the file name would be 0001.xml), for example.


What you have here is fine for a local system but note that systemid is obsolete in EAD 2002.  type="MHSfile" perhaps?


>6.  A final, non-encoding question.  For institutions that have decided to
>deliver raw xml for client-side transformation, what are the advantages of
>this approach?  I'm of the opinion that if a user is ultimately going to see
>an HTML based display, why not just send the HTML to begin with?  Am I
>missing something?  (We will soon begin delivering XML as a part of a
>digital text project, and I think the consensus here is that we will be
>converting our xml data on the fly on our server.)

Personally, I'd discount client-side delivery and rely on pre-processing to HTML. This leaves HTML on the server to be indexed by search engines, while server-side transformation might not. Sever-side transformation would be more appropriate however if you are looking at dynamic content in the finding aid, or a more complex user interface.

regards,

St.

Stephen Yearl
Systems Archivist
Yale University Library::Manuscripts and Archives