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

Lou Burnard lou.burnard at retired.ox.ac.uk
Tue Oct 18 07:51:34 EDT 2011

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 

Existing content model for revisionDesc: (list | change+)
Proposed content model for genetic-style revisionDesc: (revisionDesc | 

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

More information about the tei-council mailing list