#313 simplify content model of <subst> to add and del only


A subgroup commissioned by the Council discussed several issues relating to the model of subst (cf. tickets http://purl.org/TEI/FR/2859355 and http://purl.org/TEI/FR/3080015 ). One of the proposals made in that discussion, not reflected in the other two tickets, was that the content model of subst should be simplified.

The model currently allows:

add corr del orig reg sic unclear
damage restore supplied surplus

But we could not come up with any compelling use-case for any of these elements other than add and del.

There was a concern about the implications for backward-compatibility if the content model of subst were to be so radically restricted now. On the other hand, it was felt that the inclusion of these elements could be considered an error in the first place, which would reduce the negative impact of such an action, but we decided that the community should be surveyed with regards to current usage of subst and its children. Possible outcomes depending on the result of said survey (and discussion in council) might include:

(1) making a strong recommendation in the relevant TEI Guidelines chapters only to use add and del rather than all the available children, but not otherwise resstricting the schema (until, perhaps, a complete overhaul of the scale of P6);

(2) gradually deprecate the use of all elements other than add and del within subst, so that they are disrecommended now and removed from the schema in, say, 6 or 12 months time;

(3) move towards entirely removing these elements from subst at the next formal release.

(In other words, more discussion is needed on whether to deprecate the use of these elements within subst slowly or quickly.)


  • James Cummings

    James Cummings - 2011-08-25

    How long will this call be open? If no responses are received then I would suggest that we do either 2 or even better 3.


  • BODARD Gabriel

    BODARD Gabriel - 2011-09-29

    There were several objections on TEI-L, but to my mind most of them seemed to be appealing on the grounds of backward compatibility more than anything else. (Some may scream here that this is not the case...) I think we should go ahead with (2), but on a long timescale, at least 12 months.

  • Laurent Romary

    Laurent Romary - 2011-09-30

    We have a mechanism for this. Create a ticket in the category deprecated and add a note to the documentation. Unless there is a big opposition, this should be done before the TEI conference, so that people may express their views f2f.

  • Lou Burnard

    Lou Burnard - 2011-11-02

    I vote for quickly.

  • Lou Burnard

    Lou Burnard - 2011-11-02
    • milestone: --> AMBER
  • BODARD Gabriel

    BODARD Gabriel - 2011-11-07
    • assigned_to: nobody --> gabrielbodard
  • BODARD Gabriel

    BODARD Gabriel - 2011-11-09
    • status: open --> pending
  • BODARD Gabriel

    BODARD Gabriel - 2011-12-08

    All done (content model changed immediately rather than deprecated). Closing ticket.

  • BODARD Gabriel

    BODARD Gabriel - 2011-12-08
    • status: pending --> closed-accepted

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

Sign up for the SourceForge newsletter:

No, thanks