[tei-council] support for P4

[James Cummings]

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 
best practice.
     * Deprecated structures determined not to be in wide use 
might eventually (as discussed immediately below) be removed from 
the Guidelines.
===

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.

-James

-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford