Hi George,
(Apologies if this is becoming off-topic for the EAD list)
Performance is quite acceptable over a 14.4 modem. The
Javascript version of the table of contents expands to
any arbitrary depth. See:
http://sunsite.berkeley.edu/FindingAids/brautigan/javascript
for an example of a finding aid with a bit more hierarchy.
Even though the example I've provided is nice, I wouldn't
actually recommend this method for creating an expandable/
collapsible table of contents. It's too browser-dependent.
As I mentioned, the newest versions of Netscape, version 4.01
and 4.02, both implement Javascript far too slowly (chalk it
up to another casualty of the browser wars). Netscape is
aware of the problem and has pledged to fix it in future
releases. I'm not sure how MS Internet Explorer handles it
but I bet it doesn't at all. This method may be useful in
an environment where one has control over the version of
the browser in use, such as in reading rooms or behind the
reference desk. Our markup staff uses it locally to proof
their finding aids before we make them public. I've always
considered it bad style to insist that users use a specific
browser version. The fact is they simply won't do it.
I much prefer one of the other methods I mentioned. Create
multiple tables of contents to give the illusion of expandable/
collapsible behavior. You can see an example of this at:
http://sunsite.berkeley.edu/FindingAids/brautigan/standard
Only the container list is expandable and the series list
unfolds completely, not series-by-series. The container list
is where this toc behavior really shines and in my opinion
the usefulness of being able to expand relatively small
sections of finding aids, like the top-level <did> and
<admininfo> etc. is overblown. I like this method best of
all but that's just personal preference.
If you absolutely insist on completely expandable/collapsible
behavior to any arbitrary depth then cgi is the way to go.
It's faster than Javascript if implemented carefully and
it works on all browsers, even non-frame-capable ones. I'm
sorry I don't have an example to point you to right now.
Another option is to avail yourself of the number of free
Java tree-applets out there. Originally conceived as a
method for navigating file systems I've had some success
adapting them to our purpose.
You can certainly enable different navigator views if you
like. Just have your navigator-builder program make them
for you and create links between them. My program doesn't
do this because we haven't any use for such functionality
here.
The ead2html perl program we use locally is available at
our website. Before I reveal the URL, be aware that the
version that is there is very preliminary. It currently
only works with finding aids encoded for the UC-EAD project,
a grant-funded collaborative project to encode the finding
aids from all nine University of California campuses and
to create a union database for them. I suspect it may work
for some of your finding aids as well George since Yale's
encoding is very similar to our own. A general conversion
tool is impossible due to the lack of any unified encoding
standards within the EAD community. Once we all agree on
how our finding aids are to be encoded then we can share
stylesheets, navigators and tools such as ead2html instead
of each repository having to reinvent the wheel. Nonetheless,
I am working on an updated version of the program which will
accomodate many, many more styles of finding aids. I am trying
to write the program in such a way as to more easily allow
people with some knowledge of perl to customize it for
their own local flavor of EAD, but how successful I am,
considering some of the needless, wildly divergent encoding
I have seen out there, remains to be seen.
That url is:
http://sunsite.Berkeley.EDU/FindingAids/uc-ead/ead2html
Alvin Pollock
Electronic Text Unit
UC Berkeley Library
[log in to unmask]
At 12:53 PM 9/11/97 -0400, you wrote:
>Alvin,
>
> Very impressive!
>
> I have not been a big fan of frames as many of the sites I have
>visited (academic and commercial alike) have implemented them in ways that
>tend to leave artifacts (e.g. you click on a link to an entirely different
>site in one frame and the other frames of the original site remain present
>- I know this may be done on purpose at certain commercial sites, but I'd
>prefer to use a back command when I'm moving from site to site - or the time
>to load the various frames takes far too long - especially when I'm working
>from home with a 28.8 modem.
>
> The Berekely site, on the other hand, responds very nicely - at least
>when I'm coming in from work. Can you offer any comparisons about
>performance of the expanding/contracting outline at 28.8 links compared to
>the performance of an SGML navigator over the same equipment. My instinct
>is that the initial loading of the HTML frame will be faster but that the
>SGML navigator would respond more
>quickly once it has been loaded. Also, the example you provided is a
>relatively flat navigator - in general only two levels deep at any point
>with a single example of a third layer. Can you discuss the programming and
>performance issues in building an expandable TOC file in JavaScript when the
>TOC routinely goes to three layers and often goes to four? My point is not
>to criticize what you put up but to try to understand how you think it might
>scale?
>
> I agree that the ability to maintain links between your location in the
>SGML navigator and your location in the SGML document instance are nice but
>your example nicely shows the ability to generate expanded links from the
>TOC frame to the document frame as the TOC is expanded. The other issue I
>would ask about is whether the JavaScript/HTML approach can accomodate the
>sort of multiple navigator options that it seems most SGML products build in
>- that is to say the ability at the tool bar to switch from a navigator that
>empahsizes one aspect the document instance to another navigator that
>presents a different overview and set of links to the same instance.
>
> George Miles
>
> At09:36 AM 9/10/97 -0700, you wrote:
>>George,
>>
>>Expandable/contractable tables of contents are
>>implementable in html with frames in a number of
>>ways. They can be mimicked using multiple table
>>of contents files, they can be implemented with
>>cgi, and they can be rather nicely done with
>>javascript. If you have Netscape version 3 (don't
>>use version 4, there is a bug in Netscape 4's
>>implementation of Javascript) you can see an example
>>of a fully-expandable Javascript table of contents at:
>>
>>http://sunsite.berkeley.edu/FindingAids/arequipa
>>
>>A partially-expandable table of contents is implemented
>>using multiple table of contents files (suitable for
>>viewing on ANY frame-enabled browser) at:
>>
>>http://sunsite.berkeley.edu/snyder
>>
>>Both files were generated automatically with an ead to
>>html conversion program written in perl.
>>
>>The thing that I like about dynatext and other sgml
>>browsers, is that not only does the table of contents
>>expand and contract, but a little pointer highlights
>>the toc section that you are currently "in". If you
>>are browsing a large series it's nice to be able to
>>glance over at the toc to remind yourself where you are.
>>No web browsers that I know of can implement this yet
>>without developing a full-blown java applet.
>>
>>Alvin Pollock
>>Electronic Text Unit
>>UC Berkeley Library
>>[log in to unmask]
>>
>>
>>
>>At 11:40 AM 9/10/97 -0400, you wrote:
>>>Michael:
>>>
>>> Regarding your comments concerning the impact of xml:
>>>
>>> I have seen much discussion about the expectation that xml will
>>>provide greater
>>>flexibility and control over document layout and presentation (through a
>>>greater set
>>>of tags AND through the implementation of various style sheet conventions).
>>>I have
>>>NOT seen much discussion about the extent to which xml will provide the
>>kind of
>>>split screen navigation tools that I, at least, associate as a matter of
>>>course with
>>>SGML. One of the reasons that I have not been especially impressed by
frames
>>>within HTML is that while you can use a frame page to set up a series of
>>>links, you
>>>cannot apply the outline expansion/contraction features that seem to be a
>>basic
>>>part of SGML. What can you tell me (us) about XML and navigation?
>>>
>>>George Miles
>>>Yale Collection of Western Americana
>>>
>>>
>>>At 09:52 AM 9/10/97 -0500, you wrote:
>>>> Let me share the following information on style sheets and
>>navigators
>>>>in response to the numerous recent queries on the subject. Assuming
>>>>that most of you wish to use a helper application like Panorama
>>>>(www.inso.com) or Multidoc Pro (www.citec.fi) with your web browser
>>>>(Netscape Navigator or Microsoft Internet Explorer), I will focus on
>>>>those products. Other delivery methods- DynaText, Open Link, DynaWeb-
>>>>have their own styles methods. What I say hereafter about Panorama is
>>>>based on personal experience; comments on Multidoc Pro are second hand
>>>>and therefore trust that there will be additions or corrections from
>>>>those more familiar with this product.
>>>>
>>>> Panorama and Multidoc Pro seem to use the same underlying search
>>engine
>>>>or at least use the same type of style sheets and navigators. These
>>>>particular stylesheets and navigators (S&Ns) are themselves SGML-encoded
>>>>documents, constructed according to two dtds created by Synex
>>>>Information AB of Sweden. Their dtds maybe found in Panorama Pro in
>>>>the catalog subdirectory as the files sheet.ent and nav.ent. Panorama,
>>>>at least, provides no direct technical documentation, such as a tag
>>>>library, for these dtds.
>>>>
>>>> As these stylesheets and navigators are simply ASCII SGML
files, one
>>>>could use a basic text editor such as the Windows Notepad to create or
>>>>edit the S&N files. More usefully, both Panorama Pro and Multidoc Pro
>>>>provide an interactive editor for creating on modifying S&Ns. You will
>>>>need to purchase Panorama Pro to create and edit them; the free,
>>>>unsupported version (Panorama Free) does not include this functionality.
>>>> (Note: this is not the same as the free demo version of Panorama Pro.
>>>>There has been considerable confusion on this list over the fact that
>>>>there are two "free" versions of Panorama- one an unsupported, view-only
>>>>version and one a limited-time, but apparently fully functioning, demo
>>>>version.)
>>>>
>>>> The Panorama manual provides adequate detail for using the
editor to
>>>>produce stylesheets. The directions for the navigator editor lack
>>>>sufficient detail to be very helpful. I have found the most useful
>>>>approach to learning how to use these tools is one of reverse
>>>>engineering. Capture an existing stylesheet and then experiment, using
>>>>the editor to see what happens as you make various changes. The styles
>>>>language and editor are actually fairly powerful. I don't know if the
>>>>editor in Multidoc Pro is better documented.
>>>>
>>>> Where do I get sample stylesheets? Easy. Every time you
>>download an
>>>>sgml file form someplace such as the LC, Harvard, or Yale sites, you are
>>>>downloading the stylesheet and navigator as well as the sgml instance,
>>>>the EAD dtd and all the assorted entity files. The files can be used
>>>>interactively at that time and are saved on your hard drive so that you
>>>>can come back and look at them later. Your browser will save them the
>>>>SGML file in a temporary directory, usually in c:\windows\temp. Check
>>>>the settings on your browser's configuration setup for the location.
>>>>Panorama will save the other files, typically in its \tmp directory.
>>>>Check the Panorama.ini file to confirm the location. Files will have
>>>>arbitrary names like 30.ssh, 15.dtd, and 25.ent. Panorama Pro also
>>>>includes several sample stylesheets and navigators in its entityrc
>>>>subdirectory.
>>>>
>>>> To test editing an existing style, just right click on an element
>>in a
>>>>document you have downloaded as it appears in the right frame of the
>>>>Panorama Pro viewer. Select Edit style and the style editor dialog box
>>>>will appear. Remember that the style for a particular element may have
>>>>been set in three ways: for that element itself in its full context
>>>>(<archdesc><C01><C02><did><unittitle>); for the element in any context
>>>>(<unittitle> wherever it appears); or by inheritance from the style of a
>>>>parent or grandparent or great-grandparent element (the style
>>>>for<C01><did><unittitle> is inherited from the style for <C01>). You
>>>>might try experimenting first with altering font styles, colors, and
>>>>sizes. Try inserting text before an element. Go to Before|Text|Specify
>>>>and insert \att(label)\t for <did><unittitle>. It will insert the value
>>>>of the attribute "label" and a tab (assuming that one has defined a
>>>>value for this attribute in the document).
>>>>
>>>> With the forthcoming xml specification we will be both free of the
>>>>helper applications (your browser will be able to handle EAD files
>>>>directly) and we will have a single styles language for xml. What that
>>>>will be has not been formally specified by the W3C group but is
>>>>scheduled to occur this fall. Microsoft has just announced that it has
>>>>made a proposal but that, in accordance with W3C requirements, cannot
>>>>comment on what it is. There are at least three suggestions on the
>>>>table, CCS (the styles language of html), DSSSL-O (which has its origins
>>>>in the sgml community), and a proposal from Bitstream with which I am
>>>>otherwise unfamiliar. Until then we must move forward with the tools
>>>>we have. Good luck.
>>>>
>>>>Michael Fox
>>>>
>>>>Michael Fox
>>>>Head of Processing
>>>>Division of Library and Archives
>>>>Minnesota Historical Society
>>>>Voice: 612-296-1014
>>>>Fax: 612-296-9961
>>>>[log in to unmask]
>>>>
>>>>
>>>
>>>
>>
>>
>
>
|