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.
The idea is nice, but would not this change break compatibility? @ordered has data.truthValue type, if we now enforce its value to ascending/etc. all actually existing docs with true/false would not be valid (unless we define it as string datatype). And anyway this modification would not answer to Sebastian request, since in <revisionDesc> <listChange> is not mandatory and you can have <change> elements as direct childs. My feeling is that we should not touch the schema (not for now) and probably use in the note for revisionDesc the same sentence of the Guidelines and of <change> note "It is recommended to give changes in reverse chronological order, most recent first." (to be correct, in <change> note the sentence should start with a "In revisionDesc... ", since in <listChange> that recommendation makes no sense). f