[tei-council] NH final but typos

[Lou Burnard]

Syd Bauman wrote:
>
>
> * I don't think the names of the various views should be capitalized.
>   They're not really proper nouns, but more importantly it looks
>   awful. 
>
>   
Looks fine to me
> * Change "his/her" to "his or her".
>
>   
Changed to "their"

> * Change "only lines and line groups" to "only metrical lines"
>
>   
OK
> * #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.
>
> * #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">
>     <p>
>       <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>
>     </p>
>   </egXML>
>   
Also a plausible encoding but presumably not close to the original, and 
in any case notas good for the pedagogic reasons that this passage was 
chosen in the first place.

> * "... 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.
>   
agreed: done
> * "There are several variations on this method of encoding:</p>": We
>   should not end a paragraph with a colon.
>   
indeed not. tsk tsk.

> * 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.)
>   
This is something we disagree on, fairly fundamentally, so I am not 
going to comment further. In any case, we don't have time to make 
further substantive revisions in this version.

>   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. 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.)
>
>   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.
>
>   
I disagree even more with this assertion, regrettably. It is not an 
abuse to mark one or both ends of a range by means of an <anchor>. There 
are quite a few places in the Glines where we do exactly like that.


> * 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 agree that these suggested names are over long and a bit weird, but I 
can see no reason at all why they should depart from current naming 
practice.
> * 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.
>
> * Para starting "Finally, elements that are normally used ..." up to
>   the <egXML>:
>   - <l>, generally speaking, cannot easily be encoded this way (the
>     content model of <lg> has to be modified)
>   - "they serve as empty boundary delimiters when": insert "segment"
>     before "boundary"
>   
OK
>   - attributes are not added to content models in the vernacular; how
>     about "are defined"?
>   
OK

>   - I think the parenthetical should be a footnote.
>   
I have promoted it to a sentence for now.
> * "... to an existing TEI milestone or anchor tag automatically
>   without ...": besides the mis-match in number, it is *not* a
>   requirement that they be transformed into <milestone> or <anchor>
>   elements! How about:
>      ... and if the modified elements and attributes can be mapped
>      directly to existing TEI markup structures automatically without
>      loss of information
>   
better

>   
> * "... interpretations of the <choice> <expan>Noun Phrase</expan>
>   <abbr>NP</abbr> </choice> <q>fast trains and planes</q>.
>   
>   "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 don't known what the <choice> is doing there either so I killed it. 
The <q> should be a <mentioned> in my view.


> * "... of the phrase <mentioned>Fast trains and planes ..."
>                                 ^
>                                 lower case
>
> * <egXML> following fig 5:
>   - my gut instinct is that the subtype= values should be "phr-start"
>     and "phr-end"
>   - I really dislike overloading corresp=, but I suppose I'm alone on
>     this Island of Purity
>
> * "Despite their advantages, segment-boundary delimiters incur the"
>                                     ^
>
>   
>                                     space
>
>   
hyphenation is a bit erratic throughout: we also sometimes have 
"boundary-delimiter"; I've removed the ones I spotted

> * "This means, amongst other things, that the reconstituted document
>   may not itself be valid." I'm not sure I know what this means
>   in this context, and it sounds like a non-sequitor. 
It's not a nonsequitur,. but it is redundant, so I have removed it.
> I'm inclined to
>   delete this sentence. Furthermore, the footnote (#79 currently)
>   about rule-based languages should be on the previous sentence,
>   anyway. 
>   
and now it is!

> * #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.
>
>   
where on earth did that suggestion come from? it strikes me as pretty weird!


> * "... example, is a Prepositional Phrase, not a sentence ..."
>                      ^ lower case  ^
>   
Yes
> * "An example comes if we attempt to combine a detailed Grammatical
>   view of the Pinsky example with its metrical encoding" reword:
>
>        This problem can be demonstrated by using the <att>part</att>
>        attribute when encoding both the grammatical and metrical
>        views in the Pinsky example, as follows.
>
> * "to provide targets for <gi>include</gi>": use <gi>xi:include</gi>.
>   
yup
> * #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.
>   
This really doesnt look good, I agree. But what can one do at this stage...
>   
> * "In as much as it uses elements not included in the TEI namespace,
>   stand-off markup involves an extension of the TEI." This is false
>   on 2 grounds: using an element outside the TEI namespace does *not*
>   make something an extension. (More later, maybe). But more
>   importantly, this method does not use any elements outside the TEI
>   namespace. (Except <xi:include>, and remember, validation is
>   performed *after* inclusion processing, so these stand-off
>   documents are still valid against tei_all.)
>
>
>   
I think it needs to be clearer that standoff per se is not an extension 
(it can't be since there are other bits of TEI which exemplify it). 
However, it is now definitely pumpkin time for this cinderella of a 
chapter...