On 28/01/13 10:13, Frédéric Glorieux wrote:
>>> Is it wrong ?
>> Not in my opinion! Though I think I would either supply @n
>> attributes
>> all the time or not at all -- or is your intention to signal their
>> presence in the source?
> For offshore operators or automatas, this rule seems to me the
> more robust.

My rule would be that I'd only provide @n to number lines 
(whether physical <lb> or metrical <l>) when there was some 
inconsistency in line numbering. (e.g. the line was numbered '5' 
but is actually the sixth line, or there are fragments of a 
manuscript and a convention as to how many lines are assumed to 
be missing, etc.)  If the line numbers are in the work and it is 
important for the reasons of encoding to capture them, then fine 
I would. Otherwise, I assume that numbering lines is something 
for processing and that computers can count.

This seems to tally mostly with what you say below.

> When a line is outside numbering from the editor point of view
> (ex: a title added by the editor, for pedagogical reason), you
> may get 6 <lb/> instead of 5, and you need an intelligent
> decision, understanding the edition rules, to not put @n on the
> title added. If there are no @n at all, you can't guess if
> numbering start at each pages, or each sections. You can render
> it nicely for a media, but the canonical reference is lost. There
> is probably a way to put some declaration in the header to
> specify a numbering scheme (like in the line numbering feature of
> a text processor), but I can't see yet a great value added by
> this extra work.
> Such rule is not the best for a TEI enabled scientific editor,
> but it seems to me open to better encoding in future, with no
> more need to go back to paper.

Dr James Cummings, [log in to unmask]
Academic IT Services, University of Oxford