Yes good point Martin, let's scratch that. On Fri, Mar 13, 2015 at 3:51 PM, Martin Holmes wrote:

On 15-03-13 12:26 PM, 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?

That's one thing you can't really do; it might be OK to make it a requirement that at least one dating attribute is there, but @when is not always the one you want to use. We often use @from with @to, and also @notBefore or @notAfter, not in combination.

Cheers, Martin

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

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

No, hold on a minute. Thinking about this again, I do think we could do better. The trouble with @ordered is that it only allows me to say "yes" or "no". It would be much more use if I could say "ascending" "descending" or "not". No default should be supplied. If the attribute is not used, then we know nothing, and the encoder asserts nothing, about whether the order in which <change> elements appear within a <listChange> is chronological, random or whatever. If it is used with the value "not", then the encoder is asserting that <change> elements are not ordered chronologically (they might be ordered in some other way, e.g. ascending importance) If the value is "ascending", they are chronologically ordered with the oldest first; if "descending", the reverse. If additionally the attribute @when (or another att.datable attribute) is supplied on one or more <change> elements , we should have a schematron rule to check that it does not contradict the value for @ordered. If the attribute is not supplied, or the value is "not" then any value/s are possible. I think that's it. On 13/03/15 20:08, Raffaele Viglianti wrote:

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

...

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

Hi Lou, On 15-03-14 03:40 AM, Lou Burnard wrote:

No, hold on a minute. Thinking about this again, I do think we could do better.

The trouble with @ordered is that it only allows me to say "yes" or "no". It would be much more use if I could say "ascending" "descending" or "not". No default should be supplied.

If the attribute is not used, then we know nothing, and the encoder asserts nothing, about whether the order in which <change> elements appear within a <listChange> is chronological, random or whatever.

Yay! Take that, <defaultVal>.

If it is used with the value "not", then the encoder is asserting that <change> elements are not ordered chronologically (they might be ordered in some other way, e.g. ascending importance)

Hmm. In that case, the attribute should be @orderedChronologically, surely?

If the value is "ascending", they are chronologically ordered with the oldest first; if "descending", the reverse.

If additionally the attribute @when (or another att.datable attribute) is supplied on one or more <change> elements , we should have a schematron rule to check that it does not contradict the value for @ordered. If the attribute is not supplied, or the value is "not" then any value/s are possible.

It'll be fun to write that Schematron. What's the "correct" order for three changes as follows: @notBefore="2015-01-01" @when="2015-01-03" @notAfter="2015-01-02" Cheers, Martin

I think that's it.

On 13/03/15 20:08, Raffaele Viglianti wrote:

...

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

...

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