[tei-council] NH final but typos

[Syd Bauman]

> ... but they satisfy the linguistic definition of sentence.

Doesn't every independent clause?


> It is not unusual to put new utterances in paras and it helped with
> the example.

Ah! Thank you. I had wondered about that after Lou didn't see it my
way, but found that only 1 of the 2 new paragraphs is aligned with a
new utterance.


> It's too late for that, I think. And it involves areas that we lack
> consensus on at the moment.

My point was that as it currently stands it implies something we lack
consensus on; if we re-arrange it just a bit, it loses that
implication. 


> I'm not sure what is to be gained: they seem self-explanatory, to
> me--in fact that's their main advantage. In the earlier version
> this is the section that seemed to drag to me, because it keep
> demonstrating what were in essence quite minor variations on the
> same theme. Since the custom elements are in essence a variation on
> the principle exemplified by anchor in my rewriting (i.e. that you
> can mark the start and end points) I didn't see the need to make
> people read through coding that was identical except for the
> specific name of the element.

I think maybe you mis-understand my complaint -- I'm not suggesting
we add further nuanced segment-boundary delimiter examples, I'm
suggesting we delete this one. It is an extension that adds nothing
over and above the previous <anchor> example.


> I did this because it usually is in linguistic discussions. As is
> Prepositional Phrase. And this example is being explained
> linguistically.

But the linguistics (self-admittedly, I think) do it for the wrong
reason: CLUITA (capitalize letters used in the acronym).


> Sorry that wasn't meant as a method, it was meant to show that the
> sentences were related to each other so the reader could understand
> the example.

So let's drop the n= attributes; better to ask the reader to figure
out which <s> elements are related than give the impression that
co-indexing with n= is a good idea.


> I was wondering if the solution to this might not be to explain the
> namespace in the comment directly above it within the egXML.

Better than nothing, for sure.