Re: [tei-council] Order in listChange

Thank Lou, this makes a lot of sense. We may still want to drop this sentence from the Guidelines "Conventionally change elements should be given in reverse date order, with the most recent change at the start of the list". Or if we still believe that there is a convention, then we could go ahead with Sebastian's suggestion of dropping the "should". Raff On Fri, Mar 13, 2015 at 4:03 PM, Hugh Cayless wrote:

It is at least technically possible that if you're using a DVCS like git, changes might be applied to a file in a different order than they were committed. It's a mess and each project will have to impose its own organization on things. I'm with Lou on this one.

On Fri, Mar 13, 2015 at 3:58 PM, Lou Burnard

...

wrote:

...

Sadly this is more complicated than it looks.

The @ordered attribute was introduced at the time that the semantics of <listChange> was (slightly) expanded to allow for its use within the genetic editing context, where some people feel strongly that the ability to identify distinct states in the versions of a text ought to be specifiable without also specifying a chronological ordering. So sometimes @ordered="false" means "these changes can be read as occurring in any order", and that has nothing at all to do with the original use of <change> within the <revisionDesc> which definitely has to do with chronology.

Now, considering the case when @ordered="true": my reading of the discussion is that some people (e.g. me) were always absolutely sure that the ordering ought to be "most recent first"; and others (e.g. Paul) equally certain that it ought to be "most recent last". Yet others could not see what the fuss was about since <changes> are in any case explictly datable (with @when). Hence the ordering could only ever be a matter of convention, which projects might elect to do either way, but which the Guidelines should not impose.

My recommendation now would be therefore that we should not introduce any change. Certainly I think it would be wrong to impose a chronological ordering in either sense: that will just annoy those who feel certain on the issue by invalidating lots of existing data. A project can always impose its own constraints on this matter, using schematron to check, if necessary.

On 13/03/15 19:26, Raffaele Viglianti wrote:

...

Hi all,

I just wanted to do a final check with you before acting on Bug 706 https://sourceforge.net/p/tei/bugs/706/.

The comments seem to favour imposing a reverse chronological order of changes on listChange, but that would contradict the role of the optional attribute @ordered.

Should we impose a reversed chronological order only when @ordered=true? Should we go as far as making @when required?

The examples on the guidelines suggest a reverse chronological order when there is no @ordered and a chronological order when @ordered=true

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

Thanks for your input, Raff

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived