[tei-council] An Xmas present for discussion

Martin Holmes mholmes at uvic.ca
Mon Dec 21 10:59:54 EST 2009


Hi James,

Lou's ticket looks uncontroversial, has few side-effects I can think of, 
doesn't break any existing documents, and affects only a few elements 
(anchor cb fw lb milestone pb), so I'd vote for going ahead with it.

The other one is much more complicated. I'd like to see some examples of 
how using an empty div with @spanTo would help specific markup issues, 
and as you say I'd like to hear Syd's possible plans for "something better".

Cheers,
Martin

James Cummings wrote:
> Dear TEI-Council,
> 
> Here is my Xmas present to you.
> 
> At the last teleconference we were slowly going through feature 
> requests but did not have time to make it to two that I was meant 
> to report on.  If we had, what I would have said was that these 
> need a significant amount of discussion before consideration, and 
> we would have moved on to the next items.  However, instead of 
> waiting for the next teleconference to say they need more 
> discussion, how about I just post them up here and encourage 
> everyone to go read them, discuss them here, and/or comment on 
> the tickets.
> 
> The reason I'm suggesting we deal with them together, while they 
> are about different things really, is that I believe they are 
> both entwined with the same issue of methods of spanning over 
> hierarchies.  The two tickets are:
> 
> "Make all milestoneLike elements spanning"
> http://sn.im/tei-fr&aid=2859183
> 
> and
> 
> "Add more elements to att.spanning with schematron constraint"
> http://sn.im/tei-fr&aid=2834511
> 
> The first of these #2859183, submitted by Lou, argues that all 
> current model.milestoneLike elements should also be added to the 
> att.spanning class.  This would give things like <pb> a @spanTo 
> attribute so you could do something like:
> 
> <p xml:id="para1"> ... <pb n="1" xml:id="pb1" spanTo="#pb2"/> ... 
> </p>
> <p xml:id="para2"> ... <pb n="2" xml:id="pb2" spanTo="#pb3"/> ... 
> </p>
> 
> which would allow much easier processing into page-based units. 
> This idea has some merit and implements a horse-like structure in 
> documenting the alternative hierarchy.  That said, one could do 
> without this if the two hierarchies were otherwise known to 
> processing. (i.e. xsl:for-each-group on <pb> doesn't need to know 
> the @xml:id of the next one... it just uses the next one).  It is 
> the cases where one automatically wants to do this or there are 
> more than one level of conflicting hierarchy that would make such 
> metadata necessary.
> 
> The second #2834511, submitted by me, is basically the same kind 
> of idea but applied not just to model.milestoneLike elements. 
> The suggestion here is to apply it to structural elements like 
> div/p/lg/l/ab and transcriptional elements like 
> add/del/subst/abbr/sic/orig and seg.  The usage would be to allow 
> these elements to be 'empty' under very specific circumstances 
> and to add schematron-rules to attempt to enforce those 
> circumstances.  The proposed rules would be:
> 1) if the element is empty it must have a @spanTo attribute
> 2) the @spanTo attribute must point to an @xml:id in the document 
> (i.e. starts-with(@spanTo, '#'))
> 3) the @spanTo attribute must point to an @xml:id attribute which 
> follows the current element.
> 
> SydB comments on this last ticket (but it would apply to both of 
> course) that he believes att.spanning is broken-by-design, but 
> then didn't come back and explain what he meant or how to fix it.
> 
> I thought you might like to improve these suggestions, destroy 
> them, or otherwise discuss them into the ground.
> 
> Merry Xmas,
> 
> -James
> 
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> .
> 

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)
Half-Baked Software, Inc.
(mholmes at halfbakedsoftware.com)
martin at mholmes.com


More information about the tei-council mailing list