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

[Martin Holmes]

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

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)