search

TEIC / TEI

The Text Encoding Initiative Guidelines
https://www.tei-c.org
Other
276 stars 88 forks source link

On the content model of `<revisionDesc>` #2420

Closed sydb closed 11 months ago

sydb commented 1 year ago

[Credit: issue noticed by Julia Flanders.]

Currently the content model of <revisionDesc> permits either a <list>, or a <listChange>, or a sequence of one or more <change> elements:

  element revisionDesc {
    ( list | listChange | change+ )
    }

There seem to be at least 2 problems here:

  1. <listChange> should be repeatable inside <revisionDesc> — it (<listChange>) is a member of att.typed, and reasonable cases can be made for using it to group lists of changes in the revision description.
  2. An empty revision description is not allowed, but might be useful for indicating “no revisions have been made”, and allows for valid templates to have changes filled in later.

A real-world case for (1) is a project in which editors have a workflow of tasks to perform on a file (e.g., proofreading, providing bibliographic entries for quotations, and annotating foreign words); simultaneously the publishing technologists will often execute changes in a file (e.g., “converted some of the 1st children of <div> from <label> to <head> per new encoding guidelines”, or “switched @rend to @rendition in those cases where same rendition was used many times”). Of course the project could get around this in a variety of ways, for example using @type on each and every <change>, and sorting by it to make it easier for the humans. Or nesting 2 <listChange> elements inside a <listChange> inside the <revisionDesc>. So this does not strike me as urgent. But really, I do not see any reason not to have multiple <listChange> as direct children of <revisionDesc> (and further, think having only 1 is silly … what function does it serve?) Thus my suggested content model would be

  element revisionDesc {
    ( list* | listChange* | change* )
    }
JanelleJenstad commented 1 year ago

I'd welcome this change. As projects get older and change hands, multiple <listChange> elements would be valuable -- one list for each phase of the project. I have a use case if you want an example for the Guidelines.

skurzinz commented 1 year ago

I don’t see any reason not to allow multiple <listChange> elements there. Also changing this would not contradict anything in the current state of the Guidelines AFAICS…

sydb commented 1 year ago

Council F2F agrees this is a GO for @trishaoconnor to impliment as:

element revsionDesc {
  ( list+ | listChange+ | change+ )
  }
trishaoconnor commented 11 months ago

Updated the content model for <revisionDesc> as per last comment by @sydb. Could not test the build in Docker so I've created a pull request just in case: #2482.