[tei-council] support for P4

[Martin Holmes]

All good points, and TCW09 is the reason I'm sure I'm in a minority. But 
this:

> 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.
> ===

is basically going to get us even MORE ways to do the same thing than we 
had before, surely?

Anyway, I see your reasons for keeping P6 out of the survey.

Cheers,
Martin

On 11-09-26 11:02 AM, James Cummings wrote:
> 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
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)