As I have articulated elsewhere (both on line and in print), there will
always be a stress between the requirements of processing (especially local
and immediate processing) and of "interchange" when considered in the
abstract (which includes platform-dependency issues, data longevity etc. etc.)
Balancing this stress is, simply, the work of design. Even if you take TEI
straight off the shelf, there will be plenty of design issues. (Nor has
anyone I know of argued, except possibly in the most casual and uncommitted
way, that TEI does all the design work for you. On the contrary.)
I agree wholeheartedly with Michael and with Ingo. On the other hand, I
don't take Syd's cautions to be meant in a dogmatic spirit of "Thou Shalt
Not", but rather as a caution (garbed, perhaps, in an arguable assertion
that purist TEI conformity is a good in and of itself) that we not -- ever
-- forget the competing requirement for interchange (data longevity, etc.)
that the TEI is so successful at addressing.
I also agree with Ingo on the very interesting point that the more a
project seeks to push the edges in the realm of display and functionality,
the more necessary it will be to push the balance of requirements towards
suitability for (an immediate, particular kind of) processing, as opposed
to interchange and abstract conformity to the letter of the guidelines.
Yet I also agree with him -- and again with Syd, I hazard -- that the TEI
has long shown itself to be very flexible and well-suited for just this
kind of experimentation, while maintaining a remarkable capacity to stay
"TEI". While these two requirements may often be at odds, experience and
history also show that they really go hand in hand. Experimentation is not
only a way of making something new and cool; it is the first step in
deriving the best practices that undergird the next wave of standards. And
on those standards are built the tools that allow not only interchange, but
also further experimentation.
At 05:01 PM 7/15/2002, Ingo wrote:
>I am grateful that Michael Beddow has argued in favour of
>not ignoring issues of displayability of a TEI document in the markup
>I would like to make the following (partly additional) points.
>Some of the arguments suggest that taking issues of XSLT processibility and
>displayability of a TEI document into consideration by necessity
>compromises the markup. I don't think an uncompromised TEI markup and
>considerations of presentability necessarily clash.
>As long as the decisions made are indeed in accordance with the guidelines,
>why should letting ease of XSLT processing shape it be a problem?
>TEI is by no means only meant for archivisation of texts, and processibility
>and presentation of a given TEI-text do play a role:
>"Since they [the Guidelines] contain an inventory of the features most often
>found useful for text processing, the Guidelines also provide help to those
>creating texts in electronic form."
>"Although they [the Guidelines] focus on problems of representing in
>electronic form texts which already exist in traditional media, these
>Guidelines should also be useful for the creation of electronic texts."
>(Both quotes from the introduction to the Guidelines, chapter 1[.0])
>I can't see how the creation, and publication, of electronic texts with TEI
>should be possible without some thoughts about presentation, ie how the TEI
>markup could translate into display. Clearly, one can't simply ignore the
>question if one plans some kind of publication.
>And when transcribing, say, a previously unpublished manuscript text
>using TEI, what is effectively done is to edit, ie publish, this text.
>To me it would seem to be a loss to not take advantage of the versatility of
>XML+XSLT and all the options this offers in the production of a TEI document
>that can be both transcription and edition.
>It is in fact the flexibility of XML and XSLT that I find one of the most
>attractive and fascinating features of TEI.
>It opens up whole new dimensions of editing a text. That it is possible to
>produce something like three-dimensional editions, as it were, and no longer
>be restricted to the two dimensions of paper-editions, is a very strong
>point in favour of the TEI scheme and makes it potentially very attractive
>to anybody with editorial interests.
>Which editor would, a decade ago, have dreamed of being able to display the
>same text in different degrees of 'diplomaticity', or as a running text,
>etc., and this with hardly any effort at all?
>Multiple hierarchies are a marvellous thing, indeed.
>However, it would mean to considerably restrict the opportunities of
>"flexible editions" if not at least some thoughts are given to what markup
>is needed for the different display(s), and which markup will serve one's
>Please do not misunderstand me: I'm not arguing against the
>'structure-not-presentation' approach of the markup. It is exactly this
>approach that makes this flexibility possible after all.
>Last not least, we, that is the project, don't really have the choice but to
>think about display.
>Like many other projects, I suppose, we need to show something for the money
>we got, and this pretty soon after the project is finished, and something
>that's not too difficult to consume by our potential 'customers'. And XML
>texts per se are neither very impressive nor easily consumable...
Wendell Piez mailto:[log in to unmask]
Mulberry Technologies, Inc. http://www.mulberrytech.com
17 West Jefferson Street Direct Phone: 301/315-9635
Suite 207 Phone: 301/315-9631
Rockville, MD 20850 Fax: 301/315-8285
Mulberry Technologies: A Consultancy Specializing in SGML and XML