On Sat, 2003-07-12 at 19:07, Daniel O'Donnell wrote:
> First: the EETS experiment is a nice site. Since I am pulling my hair
> out about design at the moment, I noticed that it has two potential
> problems that might want to be considered in general for the production
> version of the standard stylesheets, however: the banner contains unique
> information (though not very much other than the title) that won't show
> up in a screen reader or text-only browser; and the use of a fixed width
> banner image stops the text fitting screens smaller than 640x780 (e.g.
> PDAs or reduced-sized windows). Are you thinking of separate stylesheets
> for aural, handheld, print contexts?
The two aspects of the design which you have noticed were insisted-upon
by the client. I advised against it, in moderately forceful terms, but
in the end did as I was told. I agree, others should not follow this
> At the same time however, it seems to me that there should be a
> mechanism for attaching a single TEI compliant bibliographic header to a
> system of files rather than a single file
my view is that one should stop thinking in terms of files, but rather
in terms of trees. The EETS setup has loads of files on disk, which may
or may not bear any relation to the theoretical structure. What Lou
outlined _does_ have a single teiHeader for the whole work, but each
text is in its own isolatable <text> tree. If you want to think of
<tree>s as files, thats OK. The only issue is cross-linking; if you use
ID/IDREF pairs, this method of working is problematic (ie the individual
files do not parse). So you need to use more sophisticated pointers.
If we used a teiCorpus to categorize a whole slew of files in multiple
directories (eg a web site), each file could be its own TEI.2, as
normal, but on demand one would process the system as a whole with the
> Whereas in print
> bits of material need to be assigned a specific place in a linear
> structure (e.g. glossaries and appendices go in the back matter),
> electronic documents can place this material in several spots at the
> same time or generate it dynamically: e.g. lines from the glossary
> showing up in the text; quotations from the text showing up in the
> introduction; fragments of appendices showing up in chapters).
the text may _show up_ in various places, but I don't believe that each
piece does not have a logical home in the original structure.
> example from the EETS ancrene wisse site, I think, is the appearance of
> translations: if I understand things correctly, these show up in a
> couple of different places depending on the links followed. Since Lou
> and Sebastian encoded this document using linear print structure
I don't think we did, actually. we structured it in a way which we
believed reflected the state of research. we later derived a
> if notes or glossary entries can show
> up in various places in the realised document, they are not really
they are backmatter in the sense that they are additions to the text
made by the modern editors. the <body> is reserved for versions of the
> <database of narrative units such as introductions, prefaces (i.e.
> material for which their is likely to be only one representation in the
> <database of non-narrative material such as manuscript readings,
> glossary entries, notes, images, etc. (i.e. material which is likely to
> reappear at various places in the edition, including within the
> narrative units)>
thats not far off what the EETS example does.
Sebastian Rahtz Information Manager
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431