#118 ODD needs a way to indicate deprecation at next major releas


ODD needs a way to indicate that an element/attribute/class/module will be deprecated at the next major Px release of the Guidelines.


  • Lou Burnard

    Lou Burnard - 2008-08-17
    • milestone: --> 871207
  • Lou Burnard

    Lou Burnard - 2009-04-02

    If needed, we could move elements or classes into a different module.
    New feature in ODD: could add @status to *.spec

  • Sebastian Rahtz

    Sebastian Rahtz - 2010-10-20

    as requested by TEI Council, James Cummings and I met to discuss this. We concluded that a documentary attriibute on *Spec will not be hard to maintain, and will allow the TEIC or 3rd parties to build services in the future (eg showing deprecated elements in red on a web page).

    To get better value from @status, we propose three allowed values
    - deprecated: this object will disappear one day
    - unstable: this object is new, and may change rapidly
    = changed: this object has changed in some way since the last release
    the implicit default of course is "stable"
    This will allow tools to support "dont include deprecated or unstable objects", and allow for list of changed objects to be created.

    We believe that the status attribute should be accompanied by adding *Spec to att.datable, to allow finer-grained control. so

    @from indicates when the status changed to deprecated or unstable
    @to indicates when an object is scheduled to die or become stable
    @when (or @period, which may refer to releases) indicates when the object as a whole changed

    @notAfter and @notBefore mean something vaguer :-}

    these are all optional!

    All this does NOT mandate the TEIC to use all or any of these features now, but allows for gradual imprrovement in working practices. Particularly the use of status='changed' needs some technical work to automate it.

  • Lou Burnard

    Lou Burnard - 2010-10-26
    • labels: 627820 --> TEI: New or Changed Class
    • milestone: 871207 --> GREEN
    • status: open --> open-accepted
  • Lou Burnard

    Lou Burnard - 2010-10-26

    The fact that we keep referring to *spec elements suggests that maybe there is need for a more generic class "att.specifying" which supplies @status and possibly other attributes we havent thought of yet?

  • Sebastian Rahtz

    Sebastian Rahtz - 2010-10-26

    we do already have att.identified, which I think covers the case

  • Laurent Romary

    Laurent Romary - 2010-10-26

    Argh. This makes me discover that att.identified has become a hidden place for attributes which have nothing to do with the definition the class bears (but who indeed would have a good fit with the @status attribute. A good opportunity to clarify the while thing.

  • Lou Burnard

    Lou Burnard - 2010-11-01

    Added @status to att.identified , but not closing ticket pending discussion of other issues raised here

  • Sebastian Rahtz

    Sebastian Rahtz - 2011-02-26
    • assigned_to: rahtz --> nobody
  • Lou Burnard

    Lou Burnard - 2011-03-20

    Closed as there has been no further discussion and the fix implemented meets the requirement identified

  • Lou Burnard

    Lou Burnard - 2011-03-20
    • status: open-accepted --> closed-accepted

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks