[tei-council] pb, lb

Dan O'Donnell daniel.odonnell at uleth.ca
Fri Sep 28 13:17:39 EDT 2007


Would renaming them pageBegin, lineBegin etc., in the prose not go a
long way to solving some of the inconsistent use on short notice? It
wouldn't control for either this or the issue of <pb/><lb/><cb/> vs
<pb/> but it would go a good way to influencing behaviour on the first
issue right away. And perhaps a small paragraph or sentence or too in
the guidelines based on Lou's essay would help influence behaviour on
the second issue.

On Fri, 2007-28-09 at 14:35 +0200, Laurent Romary wrote:
> I would definitely support this!
> Laurent
> 
> Le 28 sept. 07 à 12:10, Lou Burnard a écrit :
> 
> > Here is a small essay on this topic, with a suggestion at the end.
> >
> > Most milestone units indicate a change of state of some kind. The
> > default assumption is that the old state ceases to apply and the new
> > state starts to apply at the point the milestone tag is inserted in  
> > the
> > text. Consequently if for some state (say "being on page 42") there is
> > no milestone, you are not yet in that state. This is the rationale for
> > saying that you must put a <pb> before the material on page 42, not
> > after it.
> >
> > There is another interpretation of milestones, which is that they are
> > solely there to mark points (like <anchor>s). In this sense, the <lb/>
> > for example doesn't really mark a change of state (from "being on this
> > line" to "being on a different line") but simply the notional point
> > between the two lines. But this looks like sophistry to me.
> >
> > I think there are two real usage issues that need to be addressed
> > somehow. The first is that *some* milestone changes imply changes in
> > others Changing from one page to the next implies of necessity  
> > changing
> > from one line to the next and (if I am doing columns) one column to  
> > the
> > next. So there is an implicit hierarchy in which inserting a <pb/>
> > notionally inserts also a <lb/> and a <cb/> at the same point, just as
> > inserting a <cb/> implies inserting an <lb/> : you just cannot have a
> > column or a line which spans a page break, without doing violence  
> > to the
> > definition of what "column" or "line" means.
> >
> > Note that this is by no means true of all milestones -- indeed the  
> > main
> > reason for introducing milestones is precisely to allow for units  
> > which
> > do not behave in this way. But, I contend, it *is* true of the three
> > mentioned here, which are also, probably, the three most frequently  
> > used!
> >
> > If you grant the possibility of "implicit" milestones (and you can of
> > course say "this is XML: we don't do minimization") then you also have
> > to confront the fact that some milestones are implicit in the  
> > deployment
> > of other elements. For example, part of the definition of <p> or <l>
> > (but not, I suggest, <item> or <div> ) is that they have an implied
> > <lb/> at their beginning. I am not, of course, talking about how we  
> > want
> > to render the things, I am talking about how we recognize them. If we
> > found in our text something which had other paragraph-like properties,
> > but didn't start a new line, we'd probably have difficulty agreeing  
> > that
> > it was a paragraph (in fact, I'm having difficulties thinking how else
> > we'd identify it at all). If we are marking up a poem, there is  
> > probably
> > an implicit <lb/> following each <l> -- so that when a metrical line
> > gets fractured by the typography, we can happily insert just one <lb/>
> > solely at that point.
> >
> > The trouble is that we have no way, currently, of formally stating  
> > these
> > rules of interdependence or implication between elements (assuming,
> > indeed, that you think they are useful). We cannot easily record  
> > that a
> > an occurrence of milestone type x implies an occurrence of  
> > milestone y,
> > nor that the presence of element a implies an occurrence of  
> > milestone x.
> > And, as I suggested above, you may plausibly say "tough: we don't  
> > do tag
> > minimization" and leave it at that.
> >
> > Since however <pb> <lb> and <cb> are so widely (and inconsistently)
> > used, I can't help wondering whether some tighter usage rules for  
> > these
> > special cased milestones only -- along the lines indicated above --
> > might not help the community. What do you think?
> >
> >
> >
> >
> > Dan O'Donnell wrote:
> >>
> >> On Wed, 2007-26-09 at 12:30 +0200, Matthew James Driscoll wrote:
> >>> I've always maintained that the "b" stood for "boundary", rather  
> >>> than
> >>> "break" (an idea I believe I got from Lou originally), and  
> >>> insisted that
> >>> they be put at the front of the thing in question -- don't make  
> >>> no sense
> >>> otherwise.
> >>
> >> I think the impetus to put them at the end comes from html:lb usage.
> >>
> >>> Matthew
> >>>
> >>> -----Original Message-----
> >>> From: Lou Burnard [mailto:lou.burnard at oucs.ox.ac.uk]
> >>> Sent: Tuesday, September 25, 2007 8:34 PM
> >>> To: tei-council at lists.village.Virginia.EDU
> >>> Subject: Re: [tei-council] pb, lb
> >>>
> >>> Dan O'Donnell wrote:
> >>>> Hi all,
> >>>>
> >>>> This is probably silly, but I've been teaching a student research
> >>>> assistant P5 and the issue came up.
> >>>>
> >>>> Was there not discussion some time ago of changing the name of  
> >>>> pb and lb
> >>>> from page break and line break to page begin and line begin?
> >>> No discussion about changing the name of the element sfaik. But
> >>> agreement to clarify that th "b" should be understood as implying  
> >>> you
> >>> put the thing at the "beginning"
> >>>>  The
> >>>> preferred convention is to put milestones at the beginnings of  
> >>>> spans
> >>>> they involve (e.g. handShift), right?
> >>>>
> >>>>
> >>> krekt. " By convention, pb/
> >>> <http://tei.oucs.ox.ac.uk/P5/Guidelines-web/en/html/ref-pb.html>
> >>> elements should appear at the start of the page to which they  
> >>> refer." is
> >>> what it says in the Good Book.
> >>>
> >>> _______________________________________________
> >>> 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
> >
> > _______________________________________________
> > tei-council mailing list
> > tei-council at lists.village.Virginia.EDU
> > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> 
-- 
Daniel Paul O'Donnell, PhD
Chair, Text Encoding Initiative <http://www.tei-c.org/>
Director, Digital Medievalist Project <http://www.digitalmedievalist.org/>
Associate Professor and Chair of English
University of Lethbridge
Lethbridge AB T1K 3M4
Vox: +1 403 329 2378
Fax: +1 403 382-7191
Homepage: http://people.uleth.ca/~daniel.odonnell/



More information about the tei-council mailing list