[tei-council] Options for freezing and/or archiving Lite

[Martin Holmes]

>> I think we did agree that Lite will be hard-linked to the P5 version
>> current at its time of freezing. This would be my preferred option.
>
> I can live with that one, but it is weird. We'd have something
> in the development tree which uses everything in its current state
> _except_ the source. Doesn't that look odd? We find an awful
> long-standing error in the content mode of <div>, its much debated
> on TEI-L, a fix is implemented with much trumpeting, and people
> look for it at the next release. But one, just one, amongst the
> distributed schemas does not have the lovely fix. Will users grok
> the magic distinction?

I agree with this -- it's going to require endless explanation.

Can someone remind me why the idea of freezing Lite came up in the first 
place? It seems to me that if it's as widely used as it seems to be, 
perhaps it should be maintained or replaced.

Would it be possible to create a version of TEI Lite that is constructed 
entirely through inclusion, without any subsequent customization? Didn't 
we talk recently about having a sort of shortcut/conveniences module 
that would provide tags such as <b> and <i>? A new TEI Lite could be 
defined as consisting of the four base modules (or most of them), plus 
the convenience module. Other people could use the convenience module in 
their schemas too, if they wanted to.

Cheers,
Martin

On 12-08-12 11:43 AM, Sebastian Rahtz wrote:
>
> On 12 Aug 2012, at 17:43, Lou Burnard <lou.burnard at retired.ox.ac.uk>
>   wrote:
>
>>> 	Lite would be compiled and released as normal with the next release, so
>>> it would end up in the Vault for that release. Following that, it would
>>> be removed from the development trunk, and all links to it would point
>>> to the Vault version. The Lite ODD file <schemaSpec> would be linked to
>>> the version of P5 it was compiled with.
>>
>>
>> I can live with that option, so long as Lite remains accessible. One of
>> the minor concerns I have is that the term "vault" does rather suggest
>> (and does currently contain) stuff which no-one needs access to in a hurry.
>>
> obviously it would remain accessible if you know the URL (ie by following
> links from the web page. But it would not appear in eg oXYgen,
> in any of the distribution stes, in Roma etc. So this would be fairly dramatic.
>
>>>
>>> 2. Freezing (no more development, but Lite continues to be built and
>>> tested as part of the build process, and remains in trunk and in the
>>> release package):
>>>
>>> 	Lite would be compiled and released with every release. It's not clear
>>> whether it would be hard-linked to the P5 version in force at the time
>>> of the freeze or not; there are advantages and disadvantages each way.
>>> Bugs emerging out of testing would be fixed, but no other development
>>> would take place, no matter how apparently attractive the suggestions
>>> might be.
>>
>>
>> I think we did agree that Lite will be hard-linked to the P5 version
>> current at its time of freezing. This would be my preferred option.
>
> I can live with that one, but it is weird. We'd have something
> in the development tree which uses everything in its current state
> _except_ the source. Doesn't that look odd? We find an awful
> long-standing error in the content mode of <div>, its much debated
> on TEI-L, a fix is implemented with much trumpeting, and people
> look for it at the next release. But one, just one, amongst the
> distributed schemas does not have the lovely fix. Will users grok
> the magic distinction?
>>
>>
>>>
>>> 3. Active maintenance (no active development except where there are
>>> strong arguments in favour, but Lite is actively built and released as
>>> normal):
>>>
>>> 	What happens now would continue to happen, and we would respond to bug
>>> reports and entertain feature requests, although we would try to resist
>>> acting on the latter.
>>>
>>
>> I would rather not go down this route. If we want to invent a new "lite"
>> let's do that, and maintain it. This one has too much historical baggage.
>>
>>
>>> Does anyone see other possible scenarios?
>>
>> Well, I suppose we could just throw it away...
>
>
> attractive, but I am not sure what message that would send :-}
>
> I have a pragmatic suggestion - keep Lite in full support
> _until_ there is a replacement. And that could be the TEI
> in Libraries set; though I have many reservations whenever
> I look at that, I think the approach is correct.
>
> Are we really prepared to have no fully supported 80/20 customization
> of the TEI in circulation? if we thinks thats the right place to be,
> then lets archive Lite fully in the Vault and there's an end to it; otherwise,
> maintain it fully. The intermediate frozen one seems (to me)
> the worst sort of vacillation.
>
> If we opt for archiving, then we need do nothing in fact.
> Lite is part of each TEI P5 release, and fully available in the
> Vault.
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>

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