Print

Print


Several observations re the EAD table model

1.  As has been pointed our several times in this forum, Panorama does
not handle the EAD table model well (or at all).  That is Panorama's
fault not the table model.  Other SGML viewers such as DynaText have
no problem at all.  That fact, of course, doesn't help those of us
reliant at this point on Panoram for web delivery of finding aids.

2.  The EAD table model is not based on CALS.  That too was deliberate.
The CALS table is little more than a spreadsheet or html table of rows and
cells that, like html, ignores all content in its markup.  That is contrary
to the spirit of EAD (and ultimately of SGML) which priviledges content
markup over presentation markup.

3.  Having said that I would point out that many have found the use of
the table mechanism unnecesary in any case.  In many instances, simple
columnar layout (of the type Box  Folder  Contents that is so common in
finding aids)  can be accommodated quite reasonably and simply using
Panorama's style sheet language.

For examples look at these two inventories.
   a.  Go to the Minnesota Historical Society's catalog at
                www.pals.msus.edu
   b.  Select Minnesota Historical Society as the institution (this is a
         union catalog)
   c.  Search for either of these collections
        Excelsior Fruit Growers Association records
        William R. Bagley papers
   d.  Select the link to the electronic version of the inventory to
        retrieve the finding aid.

   Both of these utilize a columnar layout.  There are limitations to this
approach- whatever wraps (here the contents) can occur only in the
rightmost column.  The use of relative rather than absolute tabs to set the
columns means that any given column may not vary drastically in width
unless it is right justified.  Otherwise one gets unevenly indented
columns.  With Box and folder numbers this is typically not a problem.

   Another possiblity, one you should consider in any event, is to
rethink whether or not columns are even useful.  What we take to
be obvious in our use of columns and indention to convey hierarchy is a
convention with which we are very comfortable but which patrons may not
pick up on at all.  Whatever your feelings might be on this subject, I
think that it is very important that we all individually and collectively
look at our inventories and registers with a fresh eye.  This time of
conversion to electronic delivery provides a fruitful opportunity for
doing just that, whatever mechanism we are using to delivery the
product.  It certainly has been beneficial here at MHS.

Michael Fox

Michael Fox

On Fri, 18 Apr 1997 14:32:08 -0400,
Timothy Young  <[log in to unmask]> wrote:

>Cara - In response to your comments about the inability to get
>your columns to line up in Panorama, I can report that the two expert
>Panorama users at Yale (I and a colleague) have never been able to
>make the program parse columns as intended by Panorama. Over the past year
>or so, we
>have tried many different approaches with the style sheet and the
>COLSPEC/SPANSPEC tags, but to no avail. Our opinion was that
>the discrepancy between the EAD.DTD and Panorama was to account for it.
>That is - Panorama builds tables based on CALS protocol - but the EAD
>provides for table markup using a protocol that is not strictly CALS compliant.
>(That's what we were told last year.)
>So, we shrugged our shoulders and went with what Panorama gave us.
>For the Beinecke Library finding aids, the layout and spacing of tables
>and columns looked close enough to our current online displays that
>we were content, so we decided to not even include COLSPECS and
>SPANSPECs. The Divinity Library and the Manuscripts and Archives
>Department kept those tags in their instances, anticipating the daywhen they
>would
>parse correctly.
>I write this assuming that you have been able to make make columns and
>cells appear within Panorama using the style sheet. If you are still having
>a problem
>doing that, please write me and I may be able to give you some basic
>assistance.
>
>Tim Young
>Archivist
>Beinecke Rare Book and Manuscript Library
>Yale University
>[log in to unmask]
>
>
>At 11:44 AM 4/18/97 EST, you wrote:
>>We are currently marking-up our finding aids with the Author Editor
>>Program.  We create the style sheets and navigators in Panorama Pro.
>>We have run into some difficulty editing the style sheet to format the
>>container listings.  We are unable to align the box, folder, and
>>contents even though we followed the table model offered by RLG Fast
>>track.  Does anyone have any helpful suggestions they could pass
>>along?
>>
>>Also, in accordance with RLG's table model, we insert 20 colspec tags
>>followed by 4 spanspec tags.  When viewed in A/E the start and end
>>tags for each tag appear together.  When we export in SGML and import
>>it into Panorama Pro, the 20 colspec tags are broken up, with the
>>first 10 start tags listed followed by the 4 span spec tags and then
>>the 10 end tags for colspecs.  We believe this may be the reason for
>>our container listing problems.  However, we have not yet figured out
>>a way to remedy this.  Nor, I should add, has SoftQuad.  Any
>>information will be much appreciated.
>>
>>Thank you,
>>Cara Brick
>>New York University Archives
>>[log in to unmask]
>>
>>
Effective March 15, members of the Processing Department can
be reached at individual e-mail accounts.  The naming convention is
[log in to unmask]      e.g.

[log in to unmask]
[log in to unmask]
[log in to unmask]

Processing Department
Minnesota Historical Society
[log in to unmask] or [log in to unmask]
fax  612.296.9961