[tei-council] NH final but typos
daniel.odonnell at uleth.ca
Sun Oct 28 18:20:03 EST 2007
Comments only where I don't accept Syd's argument or Lou's correction as
being totally correct. Most of this is now post P5 though.
On Sun, 2007-28-10 at 17:45 -0400, Syd Bauman wrote:
> * #NHME, 2nd <egXML>:
> Maybe I don't get this poetry stuff, but if so, lots of other
> readers won't, either. The punctuation in the extract seems (to me)
> to give pretty strong evidence that this passage is 1 sentence with
> a bunch of clauses. It looks mis-encoded.
It's not poetry, but grammar: the sequence is a series of linguistic
sentences; the use of semi-colons indicates the author saw them as being
rhetorically quite close to each other, but they satisfy the linguistic
definition of sentence.
> * #NHME, 4th <egXML>:
> What are the intervening <p> elements for? Why not just
> <egXML xmlns="http://www.tei-c.org/ns/Examples" corresp="#NH-eg-02">
> <s>Catholic woman of twenty-seven with five children And a body
> first-ratepointed her finger at the back of one certain man and
> asked me, "Is that guy a psychiatrist?" and by god he was!</s>
> <s>"Yes," She said, "He <emph>looks</emph> like a psychiatrist."</s>
> <s>Grown quiet, I looked at his pink back, and thought.</s>
It is not unusual to put new utterances in paras and it helped with the
> * "... involves marking the starting and (usually) end points of the
> non-nesting ...": either "start" and "end" or "starting" and
> "ending". But more importantly, the "(usually)" should be deleted.
> We are not, and should not, recommend any methods of encoding that
> make use of implicit, rather than marked, structures.
As Lous said, this depends on whether you see milestones as being a
variant on the boundary delimiter method. If you do, then the ends are
not always marked with this method.
> * Next para implies that milestones are segment boundary delimiters,
> which they are not. (Lou has argued a generic <milestone> could be
> licensed for such use; I think such a license would inappropriately
> lump two different things into the same bucket -- but in either
> case, it's not how <milestone> is currently licensed to be used.)
> I think the solution is to move the two paras "For some common
> structural ... would break down entirely." up into a new section
> that precedes #NHBM, call it "Transition Marking with Empty
> Elements" or some such.
It's too late for that, I think. And it involves areas that we lack
consensus on at the moment.
> However, I'm not sure the "don't use <lb>
> is if it were <l>" warning is really necessary. (I don't think I
> object, either, it just seems a little out of place.)
I think it is necessary, because otherwise it might look like we were
expanding the meaning of lb.
> Then remove "also" from "The segment boundaries also may be
> delimited by", which is now the start of #NHBM.
> * Not that I expect anything to be done about it, but let me say
> again that I think this use of <anchor> is an abuse that we may
> live to regret. Segment boundary delimiters do *not* mark points in
> the text -- they mark ranges.
De gustibus non disputandum est.
> * That said, if we are going to have this abusive use of <anchor>, we
> should demonstrate some useful practices for the value of subtype=:
> - use the name of the element that would otherwise have been used,
> not its gloss (so in this case, "s", not "sentence")
> - use something other than camel case to separate the "start" and
> "end" from the element name, lest we run afoul of someday wanting
> to have a <quoteStart> element.
> Thus I would suggest "s-start" and "s-end".
I avoided establishing a direct equivalence on purpose. It seemed to me
that you really aren't making a claim about a tei:s when you are
delimiting a non-nesting element; while calling it "s" on subtype or
whatever doesn't formally do that, I figured I'd just keep the reader
well away from the idea.
> * Given that we have an example demonstrating <anchor>, the next
> example that demonstrates custom elements either has to encode more
> information or should not exist. I.e., if we do not demonstrate
> what is to be gained by custom elements, we shouldn't bother
> discussing them here.
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.
> "Noun Phrase" should not be capitalized; the <q> should be a
> <quote>. Unless we can fix the stylesheets ASAP, we'll have to drop
> the use of <choice>.
I did this because it usually is in linguistic discussions. As is
Prepositional Phrase. And this example is being explained
> * <egXML> following fig 5:
> - my gut instinct is that the subtype= values should be "phr-start"
> and "phr-end"
Except NP...Start and NP...End both carries with it information and ties
the example coding directly to the diagrams.
> * #NHVE, first 2 <egXML>s: I am uncomfortable with implying that it
> is OK or good to be reconstituting partial elements by co-indexing
> n=. We have an attribute for the simple case, part=; we have
> attributes for the complicated case: next= and prev= (shown in next
> xmp); we have at least 2 out-of-line methods (<join> and stand-off
> w/ <xi:include>). Why are we introducing another, demonstrably
> problematic method? I realize we discuss the problems, but this
> abuse of n= rubs me the wrong way, anyhow.
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, is a Prepositional Phrase, not a sentence ..."
> ^ lower case ^
As above, this is linguistic usage.
> * #NHSO, 1st <egXML>: there is no indication, except the footnote,
> that the <include> element is from the XInclude specification.
> Either make it explicit in the example (as with the
> "http://www.example.org/cannot/really/use/XInclude" namespace), or
> use an <eg> and the correct encoding.
I was wondering if the solution to this might not be to explain the
namespace in the comment directly above it within the egXML.
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
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
More information about the tei-council