David,

Thanks for the detailed report on Panorama and its handling of the EAD
tabular layout. Given that this is a software problem, and not, as such, a
DTD design problem (I say this with confidence because two leading experts
in the SGML community, Steve DeRose of EBT, and Debbie LePeyre of Mulberry
(formerly of ATLIS) assisted in the EAD design), I recommend that any
"workarounds" with respect to "chunking" the lists into amounts that
Panorama can digest not be done in the authoritative source file (that is,
we remain true to EAD), but rather by means of on-the-fly processing when the
source is passed to a net browser/Panorama. While we have not
demonstrated that this is possible, we at Berkeley have given it some
thought and believe it to be possible.

I suspect that we can as a community work with SoftQuad on a temporary
solution that allows us to work with the current version of Panorama
without our having to compromise the intellectual structure of EAD
instances in order to do so.  This will buy us and the SGML software
vendors some time to improve their browsers. Browsers that will compete
with Panorama have been promised by SGML vendors that will remain unnamed
for quite some time now. I, for one, hope they deliver soon. And that this
prompts SoftQuad to increase the functionality of Panorama sooner rather
than later.

Daniel



On Wed, 24 Jul 1996, David Clough wrote:

> Since posting the message (quoted below) I have worked further with SoftQuad's
> technical support to discover the source of the problems we have been having at
> Yale displaying our EAD instances in Panorama.
>
> SoftQuad is concerned to point out that Panorama's table handling does work as
> documented. Panorama can handle CALS tables and row-based tables, such as those
> found in HTML, without problems. The table model in the EAD DTD, however, is
> neither standard CALS nor a simple row-based structure. Its attempt to combine
> intellectual structure with table formatting means that standard CALS routines
> will not recognize its tables.
>
> The approach we have been trying at Yale is to use the row-based feature with
> EAD tables. This has been successful with the large majority of our instances.
> However, there are limitations to Panorama's handling of EAD tables. When I
> posted the previous message it looked as though the file size of an instance was
> the critical factor. This was incorrect. Panorama can display large EAD
> instances made up of tables provided that no single table exceeds a certain
> size. It is difficult to ascertain whether this limit depends only on the number
> of rows in the table, or whether the data in the table also has an effect.
> However, we have found that in a table with little textual data, Panorama stops
> displaying the table after 1500 rows.
>
> Most of our instances are divided up into series (tagged at the <c01> level).
> Each <c01> can be specified in Panorama as a separate table, which in general
> means that the table size limitation is not exceeded. If a large series is
> divided further, say into subseries, each subseries could be displayed as a
> separate table. Most instances should be able to be displayed in Panorama using
> one of these strategies.
>
> However, there remain a subset of instances for which the strategy above will
> not work. If a series or subseries is too large to display as a whole, but is
> not subdivided, the only option would be to make the several hundred table rows
> each a table by themselves. In itself this is not a problem, but, since Panorama
> does not allow the column width to be specified, the table display ends up as a
> complete mess, with column spacing changing from line to line.
>
> Individual repositories will have to determine for themselves whether they are
> likely to need to display instances with single tables which exceed Panorama's
> limitations. Only a small number of instances at Yale are likely to present this
> problem. However, unless we change the logical structure of these instances to
> allow for Panorama's limitations, we will not be able to make them available for
> display.
>
> The ideal solution would be for Panorama to be able to handle the EAD extension
> to the CALS table model as a CALS table, rather than according to the less
> sophisticated row-based model which we are currently using. At least one other
> browser, DynaText, is able to do this, though it does not have Panorama's free
> version, which we consider important. We have submitted this handling of the EAD
> CALS extension as a feature request to SoftQuad, but I was told that it is now
> too late for any additional features to be included in the 2.0 release of
> Panorama, currently in beta testing. At Yale, we very much hope that SoftQuad
> will make this a priority in their development of Panorama. In the meantime, we
> will continue our evaluation of other browsers in order to find the most
> suitable software for the display of our SGML instances.
>
> --
> David L. Clough
> Systems Assistant, Manuscripts and Archives, Yale University Library
> New Haven CT 06510 USA
> (203) 432-1749 [log in to unmask]
>
> >The Yale team working on encoding finding aids according to the EAD DTD
> >has run up against a problem. We've found that when the size of our
> >instances exceeds around 250 KB, Panorama will no longer display the
> >whole of the file. Beyond a certain point in the document, all lines seem
> >to be typed on top of each other, resulting in an unpleasant and
> >unreadable mess. Since we will be encoding many finding aids of this size
> >and larger, this represents a serious problem for us.
>
> >We have also found that once we have files of this size navigation around
> >the document is extremely slow (Panorama takes several seconds to respond
> >to clicks in the navigator, for instance) and hyperlinks from one part of
> >the document to another no longer function.
>
> >We have contacted SoftQuad's technical support and have clarified that
> >the problem is with Panorama's display of tables. The representative I
> >spoke to said that he had successfully viewed a file of 7 MB in Panorama.
> >It is the table-handling routines which are at fault. Instances without
> >tables should not encounter these problems. Since we feel that tables are
> >the most appropriate way to display container listings, however, this
> >specification of the problem does not help us.
>
> >SoftQuad have passed the problem on to their programmers, who are
> >currently preparing version 2.0 of Panorama Pro. We are very much hoping
> >that a fix can be implemented in the 2.0 release. If not, we will be
> >forced to look for alternative browsers which can display our SGML
> >instances satisfactorily.
>
> >We hope that this information is of use to others who are evaluating
> >SGML tools for use with the EAD DTD. We would be interested to hear of
> >other repositories who have encountered similar problems, or other
> >serious problems using Panorama to display EAD instances.
>
> >--
> >David L. Clough
> >Systems Assistant, Manuscripts and Archives, Yale University Library
> >New Haven CT 06510 USA
> >(203) 432-1749 [log in to unmask]
>