[tei-council] Adopt-a-RED

Laurent Romary laurent.romary at loria.fr
Thu Mar 26 07:44:31 EDT 2009


OK. Let me try to be creative there.

I would see an elementSpec as containing a revisionDesc-like child  
indicating its history:
- when it was introduced, maybe taken up from previous editions (P1...)
- major revision it ecountered to record, for instance, semantic  
shifts , if people start to wonder why there is a descrepancy between  
an existing corpus and the actual documentation
- the current status, e.g. 'deprecated'


Le 26 mars 09 à 11:19, James Cummings a écrit :

> In message <49CB218C.8080703 at oucs.ox.ac.uk> Sebastian Rahtz <sebastian.rahtz at oucs.ox.ac.uk 
> > writes:
>>
>>> 1933481: ODD needs a way to indicate deprecation at next majorreleas
>>
>> I looked at this. Its been around since March 2008 and no-one
>> has commented on it or supported it. I know it was a council request,
>> but I just don't see it. Why not simply move the element
>> or class or macro to a module named "deprecated", so that
>> people can decide whether or not to include it?
>
> That sounds like a valid proposal to me (rather than a denunciation  
> of the request).  The request that council made was that we needed a  
> way to indicate that an element was going to be deprecated at next- 
> major-release.  Having a module and including all those elements in  
> that seems like a workable way to do this.
>
>> Does anyone remember how they imagined this deprecation would work?
>
> No idea.  I guess a special attribute on *Spec which indicated it  
> was to-be-deprecated. However, moving it to a special module pending  
> deletion seems better to me.
>
> -James
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council



More information about the tei-council mailing list