[tei-council] Order, order (was re: layers again)

[Lou Burnard]

Thanks for the feedback Martin. Just a couple of remarks:

a) I think that people might decide to order the <change>s within a 
particular <listChange> to reflect something other than chronology -- 
like put all the important ones first, or put all the ones done in red 
crayon before the ones in blue crayon. If they do, they'd probably like 
to have some way of recording that fact.

b) I note your suggestion of placing a <list> within <change> to group 
together related changes. This is already legal, of course, but I agree 
that an example might be helpful. If one is introduced, we might want 
also to reconsider the availability of <list> as a direct child of 
<revisionDesc> since we'd then need to explain in what circs

<revisionDesc>
<list>
  <item>...</item>
   <item>...</item>
</list>
...

might (or not) be preferable to

<revisionDesc>
<change>
<list>
  <item>...</item>
   <item>...</item>
</list>
</change>
...

In the *genetic* case, this redundancy doesnt arise, because we have a 
new element (<listChange>) to  group <change>s, and it can self nest. 
(See  discussion current working document)



On 18/10/11 16:29, Martin Holmes wrote:
> EDIT:
>
> "neither alphabetical nor complexity ordering CAN be intrinsic to the
> document creation/revision that the encoding is trying to capture"
>
> On 11-10-18 05:22 AM, Martin Holmes wrote:
>> I can see the need for @ordered="time:ascending" in cases where it's
>> possible to distinguish the sequence of changes, but impossible to
>> assign specific times to them through e.g. @when.
>>
>> However, @order="alphabetical" or @order="complexity:descending" don't
>> really make sense to me; neither alphabetical nor complexity ordering
>> cannot be intrinsic to the document creation/revision that the encoding
>> is trying to capture, so they're in effect editorial decisions, and
>> could in any case be achieved through XSLT processing (assuming
>> "complexity" can be quantified). I can only see the need for ordering to
>> be significant in cases where it captures something about the revision
>> campaigns (or whatever) which cannot be captured existing attributes.
>>
>> I am, like James, looking forward to having @target on<change>   for my
>> non-genetic purposes, though. Since we're revising<change>, is there
>> anything else we'd like to fix or add that doesn't necessarily relate
>> directly to the genetic module?
>>
>> One thing I've sometimes done is to capture a set of changes that take
>> place in one session like this:
>>
>> <change when="2011-10-17" who="#mdh">
>>      <list>
>>        <item>[...]</item>
>>        <item>[...]</item>
>>        <item>[...]</item>
>>      </list>
>> </change>
>>
>> None of the examples in the Guidelines shows this kind of usage. Would
>> we now be enouraging this instead?
>>
>> <change when="2011-10-17" who="#mdh">
>>      <revisionDesc>
>>        <change>[...]</change>
>>        <change>[...]</change>
>>        <change>[...]</change>
>>      </revisionDesc>
>> </change>
>>
>> Cheers,
>> Martin
>>
>> On 11-10-18 04:56 AM, Laurent Romary wrote:
>>> It would be a pity to to fragment the picture here. Could you give a strong argument why we need to order<change>    without relying on some information that is made explicit about the e.g. time at which a change is made?
>>>
>>> Le 18 oct. 2011 à 13:51, Lou Burnard a écrit :
>>>
>>>> A more serious difference, I have just remembered, is that the proposed
>>>> element for grouping<change>s together is defined in the genetic world
>>>> as being recursive, which the existing<revisionDesc>    most definitely is
>>>> not.
>>>>
>>>> Existing content model for revisionDesc: (list | change+)
>>>> Proposed content model for genetic-style revisionDesc: (revisionDesc |
>>>> change+)
>>>>
>>>> I now think this is sufficiently different that it is probably better to
>>>> introduce a new<listChange>    element after all.
>>>>
>>>>
>>>>     On 18/10/11 11:50, Lou Burnard wrote:
>>>>> Yes, as James notes, adding the pointing features required for genetic
>>>>> actually might be useful for non-genetic usages of<change>     as well. The
>>>>> other difference is that the element which groups<change>s
>>>>> (<revisionDesc>     if we stick with the idea) would gain an @ordered
>>>>> attribute. As currently specified, this is just a yes/no choice as to
>>>>> whether the order of the child<change>     elements is significant.  I
>>>>> wondered whether it might not be more useful to allow for more
>>>>> information, e.g. order="time:ascending" order="complexity:descending"
>>>>> order="none" order="alphabetical". Then I wondered whether it was a good
>>>>> idea to provide this attribute at all (for temporal ordering at least,
>>>>> <change>s can  be dated, so the presence of this attribute is an
>>>>> invitation to inconsistency/redundancy). Any views?
>>>>>
>>>>> I spent most of my journey home from wburg working on the current draft,
>>>>> more specifically on checking the test files in the sourceforge
>>>>> genetic/examples directory. More on that anon.
>>>>>
>>>>> _______________________________________________
>>>>> tei-council mailing list
>>>>> tei-council at lists.village.Virginia.EDU
>>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>>>
>>>>> PLEASE NOTE: postings to this list are publicly archived
>>>>
>>>> _______________________________________________
>>>> tei-council mailing list
>>>> tei-council at lists.village.Virginia.EDU
>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>>
>>>> PLEASE NOTE: postings to this list are publicly archived
>>>
>>> Laurent Romary
>>> INRIA&    HUB-IDSL
>>> laurent.romary at inria.fr
>>>
>>>
>>>
>>> _______________________________________________
>>> tei-council mailing list
>>> tei-council at lists.village.Virginia.EDU
>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>
>>> PLEASE NOTE: postings to this list are publicly archived
>> _______________________________________________
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>> PLEASE NOTE: postings to this list are publicly archived
>