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]