[tei-council] An Xmas present for discussion
O'Donnell, Dan
daniel.odonnell at uleth.ca
Mon Dec 21 12:00:13 EST 2009
Sorry a 'not' dropped out there: can't decide 1 without deciding 2.
-----------
Daniel O'Donnell
University of Lethbridge
(From my mobile telephone)
--- original message ---
From: "O'Donnell, Dan" <daniel.odonnell at uleth.ca>
Subject: Re: [tei-council] An Xmas present for discussion
Date: December 21, 2009
Time: 9:45:38
I agree with Martin: 1 seems pretty obvious; 2 full of implications. But I suspect that we should decide 1 without 2. I'm not seeing thecase for it myself. But let me try to get time to look at the sf entry.
-----------
Daniel O'Donnell
University of Lethbridge
(From my mobile telephone)
--- original message ---
From: "James Cummings" <James.Cummings at oucs.ox.ac.uk>
Subject: [tei-council] An Xmas present for discussion
Date: December 21, 2009
Time: 3:55:50
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
_______________________________________________
tei-council mailing list
tei-council at lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
More information about the tei-council
mailing list