LISTSERV mailing list manager LISTSERV 16.0

Help for EAD Archives


EAD Archives

EAD Archives


[email protected]


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Monospaced Font

LISTSERV Archives

LISTSERV Archives

EAD Home

EAD Home

EAD  September 1997

EAD September 1997

Subject:

Re: Stylesheets and Navigators

From:

Alvin Pollock <[log in to unmask]>

Reply-To:

Encoded Archival Description List <[log in to unmask]>

Date:

Thu, 11 Sep 1997 13:13:18 -0700

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (304 lines)

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]
>>>>
>>>>
>>>
>>>
>>
>>
>
>

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

March 2024
January 2024
December 2023
November 2023
October 2023
September 2023
August 2023
July 2023
June 2023
May 2023
April 2023
March 2023
February 2023
January 2023
December 2022
November 2022
October 2022
September 2022
August 2022
July 2022
June 2022
May 2022
April 2022
March 2022
February 2022
January 2022
December 2021
November 2021
October 2021
September 2021
August 2021
July 2021
June 2021
May 2021
April 2021
March 2021
February 2021
January 2021
December 2020
November 2020
September 2020
August 2020
July 2020
June 2020
May 2020
April 2020
March 2020
February 2020
January 2020
December 2019
November 2019
October 2019
September 2019
August 2019
July 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
February 2007
January 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
January 2006
December 2005
November 2005
October 2005
September 2005
August 2005
July 2005
June 2005
May 2005
April 2005
March 2005
February 2005
January 2005
December 2004
November 2004
October 2004
September 2004
August 2004
July 2004
June 2004
May 2004
April 2004
March 2004
February 2004
January 2004
December 2003
November 2003
October 2003
September 2003
August 2003
July 2003
June 2003
May 2003
April 2003
March 2003
February 2003
January 2003
December 2002
November 2002
October 2002
September 2002
August 2002
July 2002
June 2002
May 2002
April 2002
March 2002
February 2002
January 2002
December 2001
November 2001
October 2001
September 2001
August 2001
July 2001
June 2001
May 2001
April 2001
March 2001
February 2001
January 2001
December 2000
November 2000
October 2000
September 2000
August 2000
July 2000
June 2000
May 2000
April 2000
March 2000
February 2000
January 2000
December 1999
November 1999
October 1999
September 1999
August 1999
July 1999
June 1999
May 1999
April 1999
March 1999
February 1999
January 1999
December 1998
November 1998
October 1998
September 1998
August 1998
July 1998
June 1998
May 1998
April 1998
March 1998
February 1998
January 1998
December 1997
November 1997
October 1997
September 1997
August 1997
July 1997
June 1997
May 1997
April 1997
March 1997
February 1997
January 1997
December 1996
November 1996
October 1996
September 1996
August 1996
July 1996
June 1996
May 1996
April 1996
March 1996
February 1996
December 1995

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager