#706 revisionDesc suggesting order of changes

[Sebastian Rahtz]

the note on revisionDesc says "Conventionally change elements should be given in reverse date order, with the most recent change at the start of the list". I suggest this is over prescriptive and misleading. Either it should be a descriptive "Conventionally change elements are", which I can take or leave, or prescriptive "Change elements should be given". The combination of "conventionally" and "should" is not right.

Given that change elements should be dated, I suggest the whole notion of recommending an order isn't needed anyway. This should be regarded as structured metadata, not a human-readable narrative.

So my suggestion to drop this sentence from revisionDesc, and change a related one in <change> to read "it is strongly recommended that changes are dated".

[Martin Holmes]

Unusually for me, I vote for prescriptive here. I think it's in everyone's interest if there's one way of doing this, rather than vague recommendations, and it's a straightforward fix for anyone who's not doing it right. If you're using dating attributes, it shouldn't matter; but in actual fact, we often find ourselves using @notBefore, @notAfter, @from and @to for revisionDesc entries when multiple people work on the same file over a long period, not in a serial way, so ordering the entries by date is sometimes not trivial and involves some judgement calls.

[Stefan Majewski]

I also vote for being prescriptive, here. To avoid confusion, and as this is metadata that is created during the process of digital editing (right, this does not relate to revisions of a text prior to going digital?), I would also prefer have a mandatory date on the change.

While trying to whip up a rule to fomally check whether dated <change>s are in the correct order, I found that this is indeed ambigous when allowing for more than @when, @when-iso; especially @from @to are problematic. Some combinations are hard to put in order (without defining a sorting-precedence on either the time of start or end of change). In any case, if we want to be prescriptive, I think we should be unambigous.

One aspect we should not change in P5 though, that is the direction of ordering. While I think that actual chronologic order and document order should align, I think this is not something we should consider to change now. Generally, maybe for later, I would strongly recommend on having the earliest change first and the latest change last. Aligning the direction of document-order and temporal order makes a much stronger metaphor, which works for most people out of the box without having much to explain. Having version control systems spitting out the most recent changes first is a convenience primarily designed for the command line. This is something I am well used to, so I immediately know why <revisiondesc> is ordered as it is in TEI, but I think this needs much more clarification and explanation (and leads deviant encoding practices). Hence, I think it would be much more sensible to align this with the document-order. (Just as I expect <u>s in a theatre play to be in document-order or a <list> to be read top-down)</revisiondesc>

[Stefan Majewski]

I just noticed that the listChange is used differently in different contexts. The first example suggests a reverse chronological order, while the second example is definetly in what I would call chronological order.

http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-listChange.html

[Syd Bauman]

Yeah. I'd be in favor of just dropping "Conventionally". That said, I could probably be convinced otherwise, because they should be dated (yes, it's sometimes hard to sort, but that's the reader's problem, as it were).
But Stefan is right, ordered=true on <listchange> does not assert whether the list is in chronological order (wrong in <revisiondesc>) or reverse-chronological order (correct in <revisiondesc>), or which order is "right" for <creation>.</creation></revisiondesc></revisiondesc></listchange>

[rviglianti]

I also think that they should be dated. Is it worth going as far as

• prescribing the reverse-chronological order when ordered=true
• requiring date when ordered=false
  ? This would require a schematron rule, of course.

[Martin Holmes]

Council 2015-05-30: Green to go ahead and fix all examples to be consistently latest-first, and to remove "conventionally".