You are right, the old DynaText required X-emulation; the New Dyna*Web*
does not, it displays to a standard web browser. At our museum we are using
another product, Isite, which can be set up in two ways: it has a Z39.50
function (with an HTTP gateway if you need it) or if you just want a
simpler solution, Isite can just be set up directly as an HTTP connected
search engine. It is activated like most search engines via cgi command
that is passed on from your webserver software.

There are no special complications here; it works like any other
web-connected database directly to HTTP and the markup of the files being
served is not required to be proprietary - ours is basic, parsed,
normalized EAD encoded finding aids being served and tranlsated to HTML on
the fly. In fact when you view these finding aids, I provided the option of
viewing in either HTML (for the broad world) or in plain SGML (so that
other professionals could see what the raw data looked like underneath -
more for museum folks than you all who already know what EAD looks like).
Isite is free so that's not an obstacle. It is about as well-documented as
any free solution :) and depending on how much customization you want, can
be complicated to set up - or very easy for a vanilla package.

We felt the benefit of being able to create precise access to structured
data in a way that preserved the benefits of that structure for the
end-user and yet did not create any special software needs on their part
was worth the time spent on a server-side solution. I'm happy to share my
modifications to Isite for purposes of displaying EAD finding aids with
anyone, and the Isite folks encourage this too.

In truth, the reason it excites me to be able to do this is exactly because
we are NOT a huge, resource and expertise-rich institution (we have 1.75
fte computer staff and one server and no money) and yet even we got
something to work. So, I'm not "selling" Isite, but rather suggesting that
the range of options available is not as constrained as we might think;
therfore adoption of EAD need not be an expensive option, nor a trap, but
rather feasible and beneficial. (again our finding aids are at if you are

Anyway, I'd love to hear more on options for accessing EAD for the masses,
and of course any of the probably many things I'm not taking into
consideration here.


Richard Rinehart              | Berkeley Art Museum/Pacific Film Archive
Systems Manager & Education   | University of California
Technology Specialist         | 2625 Durant, Berkeley, CA 94720-2250
[log in to unmask] |
& Board of Directors, Museum Computer Network,

>        I appreciate the potential benefits of Berkeley's use of alternative
>ways of displaying SGML-like text, but I'm not sure that Mr. Rinehart's
>message conveys the full set of issues associated with mounting Dyna Text or
>some of the other non HTTP based SGML and SGML like products.  I hope
>someone will correct me if my understanding is wrong, but I believe that
>Dyna Text requires that the user be able to emulate an X-Windows terminal
>session.  That is not something that is built into Windows (3.11, NT or 95
>to the best of my knowledge), OS2 or the Mac operating system.
>Furthermore, there is additional setup at the server site that complicates
>matters for institutions that would like to employ standards based HTTP
>servers as their basic platforms.  I am not familiar with all of the
>technical issues, but at Yale we looked into the issues associated with
>using one of the non-HTTP based products and felt it created enormous
>user-support issues as well as issues of delivering documents that were
>coded in a proprietary rather than open-standard code.
>George Miles
>Yale Collection of Western Americana