At 02:00 PM 2/9/2005, you wrote:
>I've been thinking about our discussion of incompatibilities between tei
>and xhtml, and especially Sabastian's point that commerical browsers are
>not xml-neutral in the sense that they expect html tags like <img>
>rather than tei tags like <figure>.
>I wonder if it would it be worthwhile (or possible) to design a
>'tei-lite' that incorporated what we for want of a better word might
>call the necessary html "operational" tags like <img> in anotherwise tei
>tagset. Perhaps better described as "tei-hybrid" this set would allow
>users to code directly for browsers and CSS style.
I think I see where you're going, and the sense in it.
Yet there is a downside. Any tag set is liable to abuse once it's tightly
bound to particular application semantics -- you end up using tags to drive
behavior, irrespective of the abstract semantics that are presumably
supposed to dictate which tags you use. (Of course some tag sets -- SVG or
XSL-FO come to mind as examples -- are designed to be so bound: for them
the issues are quite different.) Of course, this is arguably not a risk to
the TEI itself, but rather to particular TEI projects. But tag abuse (and I
wonder if it's possible to have any application binding without a
corresponding potential for tag abuse) creates its own gravitational force
-- the better the hack, the stronger the force -- requiring energy on the
part of the community to repel it. And the more the community is
"attracted" into semantics as dictated by applications (and I include
"canonical" sets of stylesheets here), as opposed to abstract and
separately specified semantics that are merely *expressed* through
applications, the more other kinds of applications of the data become more
difficult, or even impossible. "Bad data floats to the top", and tag-abused
data is data that (almost by definition) is okay in one limited context,
but bad in any other. So much for interchange.
We need look no further than HTML to find examples of this, although plenty
of TEI (and worse, EAD) projects could no doubt come up with their own
examples. "Coding to the stylesheet" is an easy fix, but a bad habit, and
worse because it's contagious.
Now of course I know you're not proposing we all start abusing TEI tags.
I'm just remarking that this risk comes with the territory once
"validation" ceases to be platform- and application-neutral regimen that
can be applied and verified by anyone, and starts being a matter of whether
it happens to work in your setup.
Given this, and given the fact that we have a proven technology, XSLT, that
allows us to map arbitrary tag sets to arbitrary application semantics
(albeit expressed in other tag sets), I wonder whether the deployment of
such a "browser-ready" TEI would be worth the risk and resulting confusion.
Although sometimes seemingly heavyweight for just a simple document, the
two-layer architecture (anyone else hear echoes of Monty Python? "A path! a
path!") of TEI -> display language (with XSLT or any alternative as glue)
does have the virtue of keeping the semantic layers quite distinct.
This having been said, I also think that what you're proposing would make a
fun and fascinating study -- not least since, in defining the semantics of
whatever TEI-subset you let in, you'd come up very directly against the
stresses between tag-as-name-for-thing and tag-as-code-for-behavior, on an
element by element basis (and let's not leave out attributes :-). I have no
doubt you could come up with something better than HTML. Whether it would
be better than HTML after ten years of extensions and modifications to meet
new user requirements, is a different matter.
>I can see an obvious philolosphical objection: the resulting packet
>would not be valid tei and hence would affect document exchange and
>interoperability. I can also see an obvious practical objection: xslt
>already exists to transform tei-xml to xhtml. But, especially in the
>case of incompatibilities between tei and xhtml like paragraph internal
>block quotes, one solution might be to keep the tei whenever possible
>and only transform the bits that work otherwise work in a browser.
Well, I am assuming such a specification would be accompanied by a schema,
so you could actually have "valid TEI" at least in some sense. My objection
is rather a more subtle version of this, having to do with its impact on
intangibles such as the intelligibility and learnability of the
technologies as a whole (as they relate in their parts), with, it's true,
downstream consequences for document exchange and interoperability. But
more to the point -- such "faux interchange" (we can all see it in our
browsers so it must be interchangeable) ends up creating more work
(sometimes much more) when we discover how far it falls short of the real
thing ... so it's not really the convenience of the machines that I'm
Linda Patrik writes:
>Any development of TEI-lite would be greatly appreciated by those of us
>who do not try to do the heavy duty TEI encoding needed for archived
>material, but do try to do TEI-lite in order to develop teaching materials
>for our courses. One way to make sure that TEI is not underused is to
>allow such hybrids, so that different kinds of experimental uses could
>be tried. There are many of us using classic texts, and to justify our
>investment in TEI, we need to make the texts accessible online in html for
>our students. So a hearty endorsement of what Daniel suggested!
But TEI already allows such hybrids (as long as they are clearly labeled),
and it supports myriad experimental uses! I dare say a "standard" here
would actually have to foreclose experimental uses (or open some and
foreclose others). Nor is it clear that this "web-TEI" would actually make
an easier target for transformation than HTML ... if you're not actually
authoring in it, I'm not sure what the point would be.
But don't take my word for it! Proposals like this are always much more
compelling as demonstrations of a proof-of-concept than they are as good
ideas for other people to do work.... :->
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