[tei-council] Order, order (was re: layers again)
Martin Holmes
mholmes at uvic.ca
Wed Oct 19 12:41:59 EDT 2011
HI Lou,
On 11-10-19 09:23 AM, Lou Burnard wrote:
> 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.
That's true.
> 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)
Once again, we're going to end up with ten different ways of doing the
same thing here. Since we're going to have <listChange>, and it can
nest, I'm wondering if we should make a point of using only that in the
Guidelines, to encourage everyone to use the same structure, and
deprecate the use of <list> and <item>. We'd therefore be recommending
something like this:
<revisionDesc>
<listChange>
<listChange>
<change>[...]</change>
<change>[...]</change>
<change>[...]</change>
</listChange>
<listChange>
<change>[...]</change>
<change>[...]</change>
<change>[...]</change>
</listChange>
</listChange>
</revisionDesc>
where we have one overall <listChange>, and two nested ones, with all
change elements occurring within <listChange>. One question on this
nesting, though: can <listChange> occur within <change>? In other words,
could you have this:
<change who="#mdh" when="2011-10-20">
<listChange>
<change>[...]</change>
<change>[...]</change>
<change>[...]</change>
</listChange>
</change>
where the @who and @when attributes are defined on the ancestor
<change>, for efficiency? If not, can <listChange> also have @who, @when
etc.?
Sorry if this was already discussed at TEI or is available on a draft
somewhere -- I've been a bit out of the loop recently.
Cheers,
Martin
>
>
>
> 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
>>
>
> _______________________________________________
> 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)
More information about the tei-council
mailing list