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

[Martin Holmes]

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