[tei-council] NH

[Lou Burnard]

Syd Bauman wrote:
>> This is not conformant because it breaks the abstract model. A
>> <seg> is supposed to have some content.
>>     
>
> Indeed, that is one perspective, with which I am pretty sympathetic.
> But I then read the actual description of <seg>, which says it
> "contains any arbitrary phrase-level unit of text"; seems to me
> nothing (i.e., no content) fits into the category of an arbitrary
> unit.
>
>   

Indeed it does, but in your example the empty <seg/> element did not 
have the meaning "empty segment here" but rather "start of segment here" 
which is not at all the same thing.


>
>> If you rewrote it with milestones it would be OK though.
>>     
>
> Well it might be valid, but it would still violate the TEI abstract
> model. It would confound the difference between segment boundaries
> and milestones, which (I believe) is an important, useful
> distinction. Milestones are not arbitrary empty elements (like
> <anchor>[1]), but "simply mark the points in a text at which some
> category in a reference system changes". 

OK, I agree that "milestone" is a more specific case of
the more general "segment boundary". I think though that it's not an 
unnatural extension of the meaning you quote to say that a milestone is 
therefore a segment boundary: it marks the boundary between a segment 
without some  property and a segment  with it (or vice versa, depending 
which end you're looking at)

> Milestone elements, like the
> milestones along the road after which they are named, mark the
> passage from one to another *of the same feature*, e.g. miles of the
> road, pages of a book, or the reels of a movie. Thus in the general
> case a milestone element marks both the beginning and the end of *the
> same feature*, just with a different reference. 
Not so. It marks a transition from one state to another.


> That is, with respect
> to the feature being encoded, the stuff before and the stuff after
> the milestone are fundamentally the same.
not necessarily
>  As section HD54M puts it, a
> milestone indicates where a state 'variable' changes its value.
>   
Yes.
> One interesting feature of milestones is that the ranges into which
> they divide their ancestor element of interest (typically <text>)
> tessellate it.

Not necessarily. A milestone might be used to mark changes of speaker, 
or changes of rhetorical style, or changes of ink, for example. None of 
these tesselate the text necessarily: there may be passages where there 
is no speaker, where the style is not marked, or written in pencil.

>  This permits software to find out something about the
> current feature by looking at the preceding milestone (e.g., to find
> current page number, looking for preceding::tei:pb[1]/@n) and to find
> its edges by looking for the preceding and following milestones. 
>
> All this is patently untrue of segment boundary delimiters, which
> indicate a feature that does not tessellate its ancestor, by
> explicitly marking the beginning and the end. In some sense, they are
> not marking where a state 'variable' changes its value, but rather
> are marking the boundaries of a completely different state of
> affairs, a different variable, altogether. Unlike milestones, you
> can't just go to the preceding element to get information, as the
> preceding element may be the end of a previous occurrence, as opposed
> to the beginning of the one you're in.
>
>
>   
The phenomena you distinguish are distinct, but I think you are 
restricting the field of application for milestones too much.  If you 
want to introduce a new "milestone-like" element called "segment 
boundary" (hey, we could call it <sb/> for short), well fine, but that 
doesn't seem to be on the table.