We could start by reminding ourselves of something basic, something that has long been part of TEI lore, but which may have gotten obscured somewhat recently. I'd like to ask, in getting at this, of my audience if you would please give me a show of hands. I'd like to see what portion of you started with TEI after the announcement of P3, and how many were involved with it earlier. The reason I ask this is that I think of it as kind of a watershed. Before P3, this picture might have been generally recognized as a working assumption by the TEI. After P3, XML happened really very quickly, TEI has grown, but this particular dogma has been forgotten. The dust hasn't even settled yet with XML, and there are still rumbles of things coming. In view of that, I think it'll prove helpful to remind ourselves of the point made in this picture.

There are two levels to what I want to say today. First, there is a simple but general theoretical point I'm making. Actually that's right here on this slide: don't identify TEI with SGML or XML: think of it, rather, as something beyond itself, something expressed in but not limited to the technology of the day. But from this theoretical observation, there are specific tactical conclusions I think we can also draw. Lou asked me to think about the issue of training and how the TEI may address it. I'll have specific suggestions to make about that as well as about other burning issues of the day.

So anyway, we can start by seeing that TEI never proposes that the application of standards be so absolute as to prevent scholars or researchers from achieving their research goals. This quote is from the TEI editorial P1 document, and it doesn't hesitate to be very clear on this point.

XML complicates this situation, but it doesn't essentially change it. We can also notice that at least in theory, there's still this area over here to the left, where legitimate research goals of the “TEI” might still call for a different set of metalanguages or basic assumptions than SGML or XML.

So the question naturally comes up of what TEI is, if it's not defined as “SGML” or “XML”; and here I've got a depiction of how I think we could answer that. Any of these three things might be what TEI is -- it's all of them, but at the same time; yet if you think for a minute about these three categories, you can also perceive how they may be in tension as well as in harmony. For example, there's a tension between a technical standard, which is a good thing since it fosters interchange and a higher level of work generally, and the aims of technology, which is always trying out new things that a standard hasn't described yet.

I don't really want to linger on these ideas, however, since there's a deeper point: the true formula that defines TEI (since neither SGML nor XML do, however close TEI comes to being “an XML application for humanities research”). This is, I believe, a determination that it will work on two levels at once. At one level, various TEI practitioners will do their thing with their texts. Applications. At a deeper level, however, all TEI users will agree on a metalanguage or metalanguages that can be used to describe TEI, in particular TEI texts (that is, the encoding systems must be validable) but not necessarily only that. If we look at early TEI documentation, the roots of this thinking are clearly expressed.

It's tremendously powerful to unify on a metalanguage or set of metalanguages. Whatever this metalanguage is (and as Michael SMcQ has pointed out, that it is some metalanguage is more important than that it be any particular metalanguage), it helps to provide for unification of practice and is accordingly granted a central, even sacred status, becoming an object of study and research itself. This is the price we pay for technology, as it always is. This also accounts for the curious status of XML, and the sense that some of the more reluctant of us sometimes have, that these new standards are taking away with the other hand what they are giving with the one.

This slide tries to depict how network effects work mathematically; if you're not sure of how this works it's a worthy discussion and worthy thing to understand.

In any case, then, TEI properly works at a higher layer than SGML. We were just reminded of this again last week on TEI-L, when it again came to notice how SGML explicitly makes room in its concept of a “DTD”, semantics and semantic constraints that can't effectively be enforced by the formal declarations. (This theoretical fine point seems to have been lately forgotten as XML has gotten validation-happy. But is documentation ever in fashion?)

And TEI works at a higher level than XML too. Of course, this is where the action is: XSLT moving in, TEI-based repositories being converted over into XML, RelaxNG schemas on the way, and so forth. Yet there's that space outside again, where XML doesn't go. Ironically, we see how as thing evolve to a higher point, it takes the form of foreclosing some potentials even while it opens others.

So: what conclusions may we draw? Numerous ones. (This is an outline view. I'll talk through these in detail.)

This is the age of XML, but not the end of the story.

When it comes to schema technologies, the lesson is very simple. TEI has succeeded, both as SGML and as XML, because of the strength of its validation. TEI actually validates! Little as we know that means, it actually is the linchpin upon which everything hangs.

It is going to be extremely challenging to maintain this discipline in the face of new validation technologies. Personally I like RelaxNG and look forward to making it work in TEI-like applications. But we don't want to see TEI fragment because this group here is using this schema, while that group over there is doing something completely different.

The only real solution I see is to be ecumenical with respect to how validation is done, but strict that it be done. Likewise, requirements for interchange need to be faced head on.

When it comes to training, TEI stands to gain much from disclaiming ownership of XML. Teaching XML and all things XML-related is something TEI needs to convert from a competition (zero-sum) into a positive-sum relation. If the TEI clearly distinguishes between teaching XML and teaching TEI, it will be much the better for it. Experience with writing DTDs from scratch is invaluable for the designer of markup systems and the TEI needs to encourage this. This principle can be expressed both in intangibles -- in the attitude we take towards other XML projects (even those in our application domains) -- and in specific externals, such as the way TEI courses are structured and taught, and to whom.

Accordingly, I propose that the TEI develop XML and TEI teaching modules separately. The present policy of sponsoring training is the right one; beyond this I think TEI needs explicitly to sponsor XML and XSLT (and other) training that is not on the TEI. The TEI can encourage this also by developing a TEI-conformant teaching/presentation/curriculum document model, in which its courses can be developed and taught. And more generally, TEI needs to look to all kinds of opportunities to get involved in XML activities and projects that are not limited to TEI.

Another implication of my basic point is that TEI should not centralize applications. This may prove to be an important point as we move forward; we don't want to find ourselves designing to particular applications; but this is what naive new users often discover themselves doing. Rather, it's fortunate that the organizational structure of the TEI as a consortium provides a framework in which schemas can be defined and coordinated at the center, but applications can be pushed out to members and member organizations. Sebastian's stylesheets, for example, should be published as Sebastian's, not as “official TEI”. Then Sebastian should be eligible for an award offered from time to time for best new, or best extended, TEI application.

My final piece of advice is motherhood-and-apple pie: TEI practitioners need as much as possible to look into non-TEI initiatives with which we have something strong in common (often it's XML), and which we stand to gain from. For example, TEI needs to embrace SVG and look out for cool SVG applications that work in conjunction with TEI data.