I'd like to add some observations to those made by David Clough concerning the
problems with Panorama and the EAD DTD's table model. I should point out that
while David and I both work at Yale we are in different branches of the library
and have not had the opportunity to work together on the issues he and I are
discussing. Therefore, what may seem as inconsistency from one institution is
actually a reflection of how diverse our experiences and ideas are concerning
the new arenea opened by EAD's development.
I want to single out David's observation that the EAD does not implement either
standard CALs tables or simple HTML type tables but has instead chosen a
different approach which while it is certainly "legal" under SGML appears to
me (and I think to others) to side-step the issue of trying to separate
content description from physical arrangement. Since looking at the DTD I have
been troubled by what I think is a mistaken compromise of the basic SGML
principle of keeping content and physical arrangement as separate spheres.
In this regard, I think it is somewhat a mistake to regard Panorama as
"broken" because it fails to handle a non-standard table structure. It
would be excellent if the people at SoftQuad can fix this problem, but I
worry that although some other browsers may accomodate the table structure
at present that in truth it (meaning the table structure) sets up a series
of potential problems. Can we, for instance, be sure that Dynatext can handle
tables of any size? Perhaps its capacity is just larger than Softquad
but not unlimited.
Much of the rational behind creating a "standardized" way of encoding
archival description using SGML was that we could tap into the great many
tools and development aids that exisited for SGML outside the library world -
something unavailable to us in the MARC based world that tends to operate
only within the library world. I hope that we stay clearly in the middle
of the SGML world and do not end up creating a niche that cannot employ
basic tools.
Along this line, I would observe that one of the aspects of Panorama that
is very different from the versions of DynaText with which I am familiar
(and here I confess that I have not followed DynaText's devlopment over the
last 6 months), is that is WWW based rather than a separate client-server
model. By this I mean to emphasize that Panorama requires no specific back-end
software, whereas, I have understood Dynatext to require both a particular
client and a particular server setup. Dynatext interprets raw SGML files and
then delivers instances that only a Dynatext client can interpret. I think
that the models here are significantly different and that they have very
different implications for the ease with which users will (or will not) be
able to make use of our SGML text-bases over time. At present, I am unaware
of anyone other than SoftQuad that has written and made available a WWW
helper app for reading SGML files through the WEB. Competition is the best
means of spurring development so I hope that other products will appear (and
perhaps have done so), but I think we should be careful about what models of
distribution we adopt.
George Miles
Curator, Yale Collection of Western Americana
Beinecke Rare Book & Manuscript Library, Yale University
E-MAIL - [log in to unmask]
PHONE - 203-432-2958
FAX - 203-432-4047
|