[tei-council] support for P4
James.Cummings at oucs.ox.ac.uk
Mon Sep 26 14:02:08 EDT 2011
On 26/09/11 18:02, Martin Holmes wrote:
> Personally I think our attitude to P6 governs pretty much everything
> from here on. If we decide P6 is basically off the table for the
> foreseeable future, we're basically saying that there will be fairly
> major structural changes in P5, because P5 will have to accommodate
> everything new and different people want to do; if we accept that P6 is
> in our future, and start working on it, then P5 can remain much more
> stable, in a kind of "maintenance mode", while serious changes can be
> addressed in the context of a complete re-think.
I agree with you that there is an inevitable increase in tension
between new developments under P5 and our fear of breaking
backwards compatibility with respect to widely-used structures.
It was for this reason that I'm keen that we start using for real
the deprecation methods we introduced where possible so that we
can indeed break backwards compatibility under the mechanisms
that we agreed to.
In TCW09 we agreed that:
Council may break backward compatibility in a more substantial
and comprehensive way (as happened with the transition to P4 to
P5) only with the transition to a new major version (e.g., P6,
but not P5.99999). Such transitions should happen only in
response to the emergence of new technologies (e.g., the
transition from SGML to XML) or the development of a new
architecture that conveys substantial benefit (e.g., the
development of the new class system). Historically, new major
versions have emerged approximately every five years.
I take this to mean that the development of P6 should only start
in response either to emergence of new technologies of such
transformative importance as SGML to XML, or new architectural
infrastructure changes to the TEI. While I don't mind theorising
about what might be the kind of change that happens in P6, I'm
certainly not convinced that we are there yet. We haven't even
got to P5 2.0 yet.
In this same document we agreed that:
Council should not be constrained by a policy that bluntly
prohibits breaking backward compatibility after the publication
of P5. Council should instead feel authorized to break backward
compatibility when Council concludes that the advantages of doing
so outweigh the disadvantages.
We are allowed to break backwards compatibility as long as we do
so in the correct way.
> Personally, I like the latter option, but I suspect I'm in a minority.
> There are so many things about P5 that seem to me to be basically
> unfixable (such as the "50-ways-to-do-the-same-thing" problem). I'd
> really like to be able to start imagining something better.
I really don't see that 50-ways-to-do-the-same-thing is a)
unfixable under a P5 system of deprecation and b) really as bad a
thing as you say. It is a strength that the TEI has multiple
methods to do things because in many cases these represent
multiple desires for how things should be encoded or traditions
of textual distinction. While this might be inconvenient for
those wanting pain-free interoperability, over slimming of the
TEI itself (as opposed to customisations of the TEI) is a
potentially detrimental activity. I too want to imagine
something better (like ironing out the inconsistencies where we
don't use the class system properly). But I'm still not
convinced that the majority of this can't be done in a the P5
system that we've created for ourselves. We're allowed to break
backwards compatibility, we're allowed to introduce new
infrastructure, we're allowed to change structures, as long as we
do so in the manner we've proscribed. Namely:
In extreme situations, where Council concludes that the utility
of a component would be improved substantially by a revision that
could break backward compatibility, Council should:
1. Create the necessary new structure (class, content model,
etc.) under a new name.
2. Deprecate but retain the structure it is intended to replace.
* Deprecated structures determined to be in wide use might
be maintained in perpetuity. Such a decision would reflect
Council's expert opinion that eliminating them would be too
disruptive to existing projects to be entertained, while making
clear that their employment in new projects does not conform to
* Deprecated structures determined not to be in wide use
might eventually (as discussed immediately below) be removed from
And while this is an interesting discussion, one I'm happy to
continue, it has little to do with the survey I planned on
posting. I can indeed include a question about where the
community feels the Council should be spending its time that is
similar to JohnU's list though.
Dr James Cummings, InfoDev,
Computing Services, University of Oxford
More information about the tei-council