[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