|From Syd_Bauman@Brown.edu Wed Oct  3 04:19:13 2001
|Date: Tue, 25 Sep 2001 16:30:32 -0400
|From: Syd Bauman <Syd_Bauman@Brown.edu>
|To: Lou Burnard <lou.burnard@computing-services.oxford.ac.uk>,
|    Nic3k DeRose <Steven_DeRose@Brown.edu>
|Cc: Nicholas Finke <nfinke1@cinci.rr.com>
|Subject: review of P4 Chap 6, core
|
|My apologies in advance for not getting the chance to proofread this
|or do a better job with the directionals -- I know it's a bit con-
|fusing and inconsistent, but I've plum run <del>out of</del><add>way
|over</add> time. I hope my attempt at thoroughness partially makes up
|for it. Note that I did not look at DTD fragments very carefully, as
|it is in the DTD (or ODD file) that those count, more than here.


|*   Many (if not all) occurences of COM ("--") in the PDF turn out
|     as a single hyphen character.

Probably a  formatting problem. Can you cite an example?

|
|*   Content model parameter entity references other than m-dots are
|     not within parenthesis; looks suspicious to me, but w/o seeing
|     DTD or declaration for the various parameter entity references, I
|     can't say.

Again, without an example I'm not sure what you're getting at here.

|
|*   6.1, pages 110-111, russian fly fairy tale example: There are
|     double blanks after periods, do you really want them? (I think
|     they look silly, esp. in a fixed width typeface.)

One of MSM's little idiosyncracies, I think.


|*   Ibid: why have the default attribute values "unspecified" been
|     specified? Is there some schema TEI is thinking of using that
|     doesn't support default attributes as DTDs do? "unspecified" is
|     the default in TEI Lite XML ver. 1.3, and thus shouldn't need to
|     be specified (and looks ugly).

This is fallout from the XMLification procedure. Fixed. 

|
|*   6.2 para 2, page 111: no space between "and" and "6.4.3, Numbers
|     and Measures" ("<ptr target=COnanu>" in the P4beta .p3x file).
|

Lots of these. Fixed this one.


|*   6.2, "Hyphens", bottom of page 111, "... which is defined in the
|     standard public entity set ISOnum defined in ISO 8879 (which
|     should be invoked in the DTD subset if... ": More a work-issue
|     for P5 than a correction for now, but a pet peeve of mine. The
|     ISO entity sets are the international standard way to refer to
|     specific characters. Why aren't they all automagically included
|     in a TEI DTD? (I know that pizza chef makes it easy to include
|     them; I guess I'm arguing that they be included by default.)


Not really relevant here. But the problem is, which entity sets should
one include: isolat1, lat2, pub? in SGML or XML versions?


|
|*   6.2, "Hyphens", top of page 112, "... reported in the
|     <hyphenation> tag ... in the TEI header": Since HYPHENATION can,
|     and often should, have content (P elements), I'd prefer this read
|     "reported using the <hyphenation> element ...". (Our HYPHENATION
|     element, btw, points out in the child P element that hyphens in
|     catchwords are always transcribed as hard hyphens.)

OK

|
|*   6.2, "Hyphens", 2nd para (1st complete para) of page 112,
|     "Creators ... mid-sentence.": Maybe I'm thick, but I found this
|     confusing. I suppose the problem to me is that in my machine
|     readable texts "&shy;" *is* a soft hyphen. You mean whatever
|     horrific notation a word-processor sticks in, I suppose.
|


At this distance of time, this passage does read very oddly. I've
tried to tidy it up a bit:
  <p>When creating a machine-readable text from scratch, it is best not
 to introduce hyphenation simply to make lines of a predefined
 length, since  one cannot then easily tell whether the
 hyphens are soft or hard. When compounds or prefixed words
 are  hyphenated in mid-sentence, it may be impossible to tell whether the
 hyphenation is due to formatting or to linguistic concerns.  </p>


|*   6.2, "Dashes", page 112, "Dashes are best distinguished in form
|     by using the entity names provided in the public entity set
|     ISOpub, defined in ISO 8879: mdash, ndash, and dash": While I
|     believe this is still true in the XML word when standalone="no",
|     when you want a standalone XML document wouldn't &#x2014;,
|     &#x2013;, and &#x2010; be the best-practice representations?

Good point. Have added the Unicode values.

|
|*   6.2, p. 112: s/section6.3.3/section 6.3.3/
|

another one!


|*   6.2, "Apostrophes", page 112, "Full disambiguation of these uses
|     belongs to the level of linguistic analysis and interpretation":
|     Is that a sentence? Well, I suppose it is -- but at least my
|     illeterate American ears have trouble figuring out what it means.
|     (Next para helps make it clear.)

Stet

|
|*   6.3.1, penultimate para of section, p. 113: s/is it/it is/.

Nice one.

|
|*   6.3.3, Quotation, page 116, first list item of first para: The
|     "q" in "in dictionaries, q may be used to mark" was not encoded
|     as a GI (or at least, was not rendered as such).

OK. It is tagged, but the odd processor didnt notice.

|
|*   6.3.3, Quotation, page 119, example at top: would look much
|     better w/o whitespace before end-tag of first L element.

General problem of example formatting

|
|*   Entire chapter: the %m.Incl; parameter entity name (an entity
|     that I presume exists to help handle what used to be handled by
|     inclusion exceptions) has an uppercase 'I' in apparant disharmony
|     with the rest of the model-group parameter entity names:
|         m.addrPart, m.agent, m.bibl, m.biblPart, m.binary,
|         m.boolean, m.chunk, m.common, m.comp.dictionaries,
|         m.comp.drama, m.comp.spoken, m.comp.terminology,
|         m.comp.verse, m.complexVal, m.data, m.date,
|         m.demographic, m.dictionaryParts, m.dictionaryTopLevel,
|         m.divbot, m.divtop, m.dramafront, m.edit, m.editIncl,
|         m.featureVal, m.fmchunk, m.formInfo, m.formPointers,
|         m.fragmentary, m.front, m.globincl, m.gramInfo,
|         m.hqinter, m.hqphrase, m.inter, m.lists, m.loc,
|         m.metadata, m.morphInfo, m.notes, m.personPart, m.phrase,
|         m.phrase.verse, m.placePart, m.refsys, m.seg,
|         m.sgmlKeywords, m.singleVal, m.stageDirection,
|         m.temporalExpr, m.terminologyInclusions,
|         m.terminologyMisc, m.tpParts.
|     (From P4beta version of DTDs.)

Yes. It does. I'll think about it.


|
|*   6.3.5, p 121, 1st line after 1st quote: extraneous comma
|     "... the encoding of this sentence, might be simply ..."

Whoops.

|
|*   6.3.5, top of page 122: intra-tag hyphen and space after
|     phrase-level start-tag
|         ... I, that she is <q rend="italic" di-
|         rect="unspecified"> too wise</q>; that ...
|     also runs off R margin

Yuk. See above

|
|*   6.4, first sentence, page 122: "This section describes a number
|     of textual features which it is often convenient to distinguish
|     from their surrounding text."

?
|
|*   6.4.1, first example: space before end-Q tag.

OK
|
|*   6.4.1, 3rd example: less space-before; blank before 1st letter.

OK
|
|*   6.4.1, 5th example (1st on page 123), line 1 & 2: whitespace
|     after RS start-tag.

OK

|
|*   6.4.1, last set of examples, p. 123: stylesheet issue? not
|     enough space between different examples.

OK

|
|*   The prose is inconsistent about the use of a comma (or
|     semi-colon depending on circumstances) after the penultimate item
|     in a list written out as prose. It should in general be there.

The so-called Oxford comma should indeed be there generally, but has
been lost in a few cases.

|     Some places where it has been ommitted:
|     -   6.3.4 para 1 line 2 "quotation marks or other devices"
|     -   next line "multi-word or symbolic"
|     -   6.4 para 1 line 2 "Names, dates and numbers"
OK
|     -   6.4 para 2 line 2 "names, numbers, measures and dates"
OK
|     -   6.4.3 gloss of MEASURE "a number, a unit and a commodity
|         name"
OK
|     -   6.5.3 heading "Additions, Deletions and Omissions"
OK
|     -   6.5.3 gloss of extent= on GAP "deletion, damage or other
|         cause"
OK
|     -   6.5.3 gloss of DEL and of resp= on UNCLEAR, "letter, word or
|         passage"
OK
|     -   6.5.3 gloss of both ADD and DEL, "author, scribe, annotator
|         or corrector"
OK
|     -   6.5.3 para 2 just before 1st example, "omission, its extent
|         and the person"
OK
|     -   6.5.3, near bottom of p 135: "<del>, <corr> and <gap> tags"
|         and then "<add>, <corr> and <supplied> tags"
OK
|     -   6.5.3, 1st bullet point bottom of p 135: "(typescript, proof
|         or galley, etc.)"
OK (also removed the or)
|     -   6.10.2 last bullet point "annotation, commentary and further
|         detail"
OK

|
|*   Work-item for P5 revision: 6.4.2 should be revisited entirely. I
|     *really* don't like using n= as if it were reg= or expan=; there
|     exist standardized names for each piece of a U.S. postal address,
|     and probably for other countries' as well; only PCDATA inside
|     POSTCODE and POSTBOX seems a bit restrictive -- what if I want to
|     indicate an error w/ SIC? Or I want to indicate a digit that
|     can't be read with GAP?

Noted as a &winita; tho I cant help feeling it has rather low
priority.

|
|*   6.4.3 para 3 line 3, p 125:
|     s/kinds of application,/kinds of applications,/?

No. Why?

|
|*   6.4.3; 1st line of 1st full para of p 126: space between "Dates"
|     and ",".

|
|*   6.4.3 2nd example, top of p 126, reg="0.924m": These Guidelines
|     should give some guidance, in the form of a pointer to a
|     standards document, in how one should go about regularizing
|     measures. Aa an American I rely on NIST Special Publication 811,
|     but there must be a non-American equivalent (perhaps _Le
|     Syst&egrave;me International d'Unit&eacute;s (SI), The
|     International System of Units (SI)_ itself?); the main
|     differences would be "," v. "." for decimal point, and some
|     spellings: "meter", "liter", "metric ton", and "deka" as opposed
|     to "metre", "litre", "tonne", and "deca". Per SP811 this
|     particular attribute value should read "0.924 m" (note space).

OK. 

|
|*   6.4.1 Referring Strings, gloss on type= of RS: should there be a
|     comma after '"elements"' before "etc."?

OK

|
|*   6.4.4 Dates and Times, for this revision:
|     These Guidelines should specify "Sample Values Include" for
|     calendar=. More importantly, these Guidelines should specify that
|     the value of value= of DATE or TIME should adhere to ISO 8601
|     where applicable. Period. We could go further and point out that
|     applications may wish to stick to formats that adhere to a
|     restricted profile of ISO 8601, e.g. the W3C "Date and Time
|     Formats" NOTE (although it has not been updated since 8601 was).
|     (Corallary: references to the specific format could be dropped,
|     i.e. "usually yyyy-mm-dd" in gloss of value= of DATE; the
|     sentence about partial dates or times.)

Propose rewording please: 

Any string representing a date in standard format; recommended
form is <mentioned>yyyy-mm-dd</mentioned>, as defined by ISO 8601: 1988, <title>Data
elements and interchange formats --- Information interchange ---
Representation of dates and times.</title>

|
|*   6.4.4 Dates and Times, for P5:
|     DATERANGE and TIMERANGE are completely superfluous and should be
|     dropped. Furthermore, it should be noted that DATE and TIME are
|     provided as two separate elements for human convenience, but any
|     processing software should be capable of handling any ISO 8601
|     specification of time on either element. E.g., "my shift ran from
|     <time value="2006-12-24T23/2006-12-26T08">11 Sunday to 8 on
|     Tuesday</time> &mdash; I spent 100% of Christmas on duty". I lean
|     towards dropping the zone= attribute of TIME, too, as it is also
|     covered by ISO 8601; but it is conceviable to imagine situations
|     for which 8601 is not applicable, and perhaps a zone= would be
|     useful, then.
|

Why are they superfluous? &winita;


|*   6.4.5 and 6.5, for P5: These Guidelines should probably give
|     readers some guidance about how to handle words that need more
|     than one correction or expansion applied. I like my "tag the
|     letter, process innermost first" system (and no one has
|     demonstrated a better one, at least not to me), which is well
|     described by Carole Mah and Julia Flanders in "Scholarly Needs,
|     Encoding Challenges: Correction, Regularization, and Expansion."
|     The Brown University Women Writers Project Newsletter 2, 2
|     (1996). 
|(http://www.wwp.brown.edu/project/newsletter/vol02num02/challenges022.html)

Specific proposals for change? Cf Matthew's requirement for a <replace> tag?

|
|*   6.5 Simple Editorial Changes, para 3 sentence 1 p. 130 "The
|     first ... 'edited' form.": Confusingly punctuated.

Specific proposals for change?
|
|*   6.5.2 Regularization and Normalization, bottom of p. 132: last
|     of the four examples of marking up same passage is not preceded
|     by a colon, other three are.

?? all of them have a colon in the odd file?

|
|*   6.5.3 Additions, Deletions and Omissions; gloss of UNCLEAR, p
|     133: Inconsistency between gloss of element ("word, phrase, or
|     passage") and that of resp= ("letter, word or passage").

OK


|
|*   6.5.3 Additions, Deletions and Omissions; example at top of p.
|     135: The whitespace before first UNCLEAR start-tag implies that
|     there was a blank before the word "The" in the original. Same w/
|     the last 2 examples in the middle of the page.

Formatting. Fixed.

|
|*   6.5.3, end: the fact that status= of DEL defaults to
|     "unremarkable" is not mentioned in the text, only in the DTD
|     fragment.

Same applies to other atts. Should it be?

|
|*   6.6 Simple Links and Cross References, middle of page 137
|     (search for "SEC12"): In order to be XML and to match the IDREF
|     in the example, the example tag in the prose should read
|         ... been tagged <div1 id="sec12">, the same ...

OK. Fixed.

|
|*   6.6 Simple Links and Cross References, bottom of page 137:
|     examples would look a lot better if PTR element were on same line
|     as rest of item (at least for short PTRs).

OK.

|
|*   6.6 Simple Links and Cross References, 1st example on p 138: the
|     targType= of the first PTR is "fig"; I'm betting it should be
|     "figure".

OK.

|
|*   6.6 Simple Links and Cross References, para after 1st example on
|     p 138:
|     -   "while "targType='bibl bibl.struct bibl.full'" restricts":
|         your quotes are too smart (the &lsquo; and &rsquo; should be
|         straight).
|     -   "type=bibliog" and "target=Chom59" are missing LITs

Fixed

|
|*   6.6 Simple Links and Cross References, p 138 "14, Linking,
|     Segmentation, and Alignment , 15,": space before comma.

Generic formatting problem

|
|*   6.7 Lists. LISTs are too badly broken in P3 to address at all
|     well in this revision process. Thus I only gave this section the
|     quickest glance-over. I have written a sizeable treatise on the
|     subject which I can point you to or send along when it comes time
|     to fix LIST (note to Syd: filename "parry/repost"). In the
|     meantime:
|     -   Missing LITs in "by the tag <list type=gloss>." on p 140.
|

&winita; 

|*   6.8.1 Notes and Simple Annotation: NOTE also needs too much work
|     to be addressed by this revision, so I only scanned this section.
|     I haven't yet written a treatise on this, but would like to (and
|     for which the section on "Notes Have Structure, Too" in our
|     poster session for ACH '99 will serve as a starting point).
|

&winita;

|*   6.8.2 Index Entries, last example (p. 144): "<p> ...</p>" should
|     read "<p> ... </p>".

OK

|
|*   6.9 Reference Systems: Use of "milestone" vs "mileStone" for the
|     element is inconsistent. It is declared as "milestone" both in P3
|     and in the fragment on p. 150. As far as I can tell, since
|     "milestone" is a word (as opposed to the juxtaposition of two
|     words) it should be the "milestone" element, not "mileStone".

It should indeed. Fixed.


|
|*   6.9 Reference Systems, 3rd bullet point (p. 145): extraneous
|     comma after "markup" before "(".

OK

|
|*   6.9.1 Using the ID and N Attributes: I think the examples at the
|     top of page 146 might be clearer if they included skeletons of
|     the missing siblings, e.g.:

|     Note that I've also corrected the missing space after the elipses
|     in L n=7.
OK

|
|*   6.9.1 Using the ID and N Attributes, last para: extraneous space
|     after "31.6, Concurrent Markup for Pages and Lines" beofre comma.

|
|*   The word "CONCUR" (as in feature) is rendered inconsistently 2
|     lines before and 2 lines after the header "6.9.3 Milestone Tags".

OK

|
|*   6.9.3 Milestone Tags, para 1 line 4 (p. 148): why is "milestone"
|     italicized? (I'm not saying it shouldn't be, just that I'm
|     suspicious.)

It's tagged as a term, since this is its first mention

|
|*   6.9.3 Milestone Tags: should it be mentioned that PB, LB, and CB
|     are just syntactic sugar for MILESTONE with unit="page",
|     unit="typographic line", and unit="column"?

Yes, probably. &winita;

|
|*   6.9.4 Declaring Reference Systems, last example: inappropriate
|     midword breaks.

OK. &winita;

|
|*   6.9.4 Declaring Reference Systems, 3rd to last para has
|         <refsDecl doctype="TEI.2">
|            <p>Standard references to work, book, poem, and line may be
|          constructed from the Milestone tags in the text.</p>
|         </refsDecl>
|     which I had never noticed before, but is a perfect example of why
|     elements for discussing (SG|X)ML should be available in all of
|     TEI (not just in the p3x extensions), at least in the TEIHEADER.
|     This passage *should* read
|         <refsDecl doctype="TEI.2">
|            <p>Standard references to work, book, poem, and line may be
|          constructed from the <gi>milestone</gi> tags in the text.</p>
|         </refsDecl>
|     In any case, consider
|         milestone tags
|         "milestone" tags
|         &lt;milestone> tags
|         <name>milestone</name> tags
|         <rs>milestone</rs> tags
|         MILESTONE elements
|     instead.

<gi> is syntactic sugar for <ident type="gi">, and <ident> is a
subclass of <name>, I suppose. There is certainly a good case to be
made for reviewing the content models of several TEI header elements
(in CES, for example, they are all defined as #PCDATA!) &winita;
This section will also need to be updated when we decide what to do
about TEI xpath expressions.

|
|*   6.10 Bibliographic Citations and References, para 1, top of p.
|     152: extraneous comma between "singly" and "(".

OK

|
|*   6.10.2.1 Analytic, Monographic, and Series Levels; last line of
|     p 155: value j of type= of TITLE not in LITs; also, there is a
|     lack of parallelism here: the <title type="j"> example shows only
|     the start-tag, but the TITLE in MONOGR example shows content
|     (substituted by elipses) as well.

OK

|
|*   6.10.2.1 Analytic, Monographic, and Series Levels; example, p.
|     156: given that BIBLSTRUCT is intended to be at least
|     machine-transformed to another format, if not machine-processed
|     itself (as if transforming weren't a process!), wouldn't it be a
|     better example to include a value= on each DATE, and perhaps not
|     even include the #PCDATA?

Well maybe, but maybe not. It would need more explanation in the text
somewhere. No change made yet. &winita;


|
|*   6.10: Is it purposeful that lang= occurs only once in all the
|     examples?

Have added several more. This of course means the examples wont parse
anymore (lang being an IDREF) but it's probably better practice.

|
|*   6.10.2.2 Authors, Titles, and Editors; discussion of RESPSTMT,
|     bottom of p 158: Since the DTD no longer enforces the "one of
|     each followed by any number of either" model (a shame), should
|     the prose be changed? If the prose is to be left (which I think
|     is a good idea), the fact that the DTD does not enforce it should
|     be noted in a footnote, perhaps addressed to "those familiar with
|     previous versions of these Guidelines".

It's a constraint that the TEI schema should enforce, so I have
added the following qualification:

(This constraint is required for TEI conformance, but is not enforced
by the current SGML or XML DTD).

|
|*   6.10.2.3 Imprint, Pagination, and Other Details; gloss of DATE:
|     See 6.4.4.

?

|
|*   6.10.2.4 Series Information, 1st para: attr values not enclosed
|     in LITs.

Fixed

|
|*   6.10.4 Relationship to Other Bibliographic Schemes, list:
|     -   Lots of attr values without LITs
|     -   Gloss for "month" and "year" should read something like
|             use DATE; use the value= attribute to provide an
|             ISO 8601 format regularization

OK

|
|*   6.11.1 Core Tags for Verse, para 2, last line of p 165: the
|     example empty LB tag is missing its NET solidus. I realize this
|     is almost assuredly because the "lb" is, appropriately, encoded
|     as a GI element, and that GI elements are (not unreasonably)
|     rendered as "font(Geneva) pre(&lt;) post(>)". I see three
|     options, in (my current) order of preference:
|     1)  Change the rendering of GI to something w/o
|         pointy-brackets. (In my plain-text I use case(allcaps), but
|         that's obviously not a good idea for this purpose; perhaps
|         bold fixed-width font would be sufficient.)
|     2)  Add an attribute to GI to specify whether the element is
|         EMPTY or not, and have the stylesheet use "post(/>)" if it
|         is.
|     3)  Do neither, and remind readers that the <thing> format
|         denotes an *element* not a *tag*.

I dont see what you're fussing about. It says " the <lb> *element*",
doesn't it? How much more reminding do you want?

|
|*   6.11.1 Core Tags for Verse, 2nd example, p 166:
|     -   First, the example would look *much* better if the end-L
|         tags were at the end of each encoded line.

Agreed: done

|     -   Second, the values of type= are specified as lower case, but
|         the declaration below is for upper case. Thus:
|             <l>Thou fumblest <name>Eros</name>, and my Queenes a Squire</l>
|             <l>More tight at this, then thou: Dispatch. O Loue,</l>
|             <l>That thou couldst see my Warres to day, and knew'st</l>
|             <l>The Royall Occupation, thou should'st see</l>
|             <l part="I">A Workeman in't.
|             <stage type="mix">Enter an Armed Soldier.</stage></l>
|             <l part="F">Good morrow to thee, welcome. ...</l>

OK

|     -   Third, the habit of specifying defaulted attributes in the
|         examples (which I really don't like) points to at least two
|         problems. Since there has been no discussion of The type= of
|         STAGE, the reader at this point doesn't understand what this
|         "mix" is a mix of. Furthermore, it's hard to imagine such a
|         straight forward entrance being encoded as anything other
|         than type="entrance", or no type= at all: therein lies the
|         problem -- I think (perhaps for P5?) that having type= of
|         STAGE default to "mix" is a bad idea. If #IMPLIED is for some
|         reason insufficient, how about "unspecified" or some such?

OK, I think I'll stretch a point and change the default value to
#IMPLIED. We certainly don't need the type="mix" here anyway.


|         P.S. In P4beta 10.2.3 the "suggested values include" list for
|         type= of STAGE has "mixed", not "mix".

Well spotted! This means I can change the default to #IMPLIED with a
clear conscience, since the existing state of affairs is clearly
Wrong.


|     -   Lastly, this seems like a bad example to me: why isn't the
|         STAGE just in a single L element that does not use part=?
|         I.e.
|             <l>A Workeman in't.
|             <stage type="mix">Enter an Armed Soldier.</stage>
|             Good morrow to thee, welcome. ...</l>

Yes. We need a better example, and there is already a note in the text
to that effect! Please suggest one.... &winita;

|     -   However (and for P5 more than now), this example
|         demonstrates a shortcoming of the content model for LG: it
|         (usually) makes no sense to stick a STAGE in the middle of a
|         metrical line (after all, it doesn't scan with the rest). 

So the example isn't that bad then!

|In early 1999 the WWP altered the content model to allow STAGE
|         as a direct child of LG (e.g., between Ls).

I assume you're proposing this as a change to the content model of
<lg>? &winita;

|
|*   6.11.1 Core Tags for Verse, bottom of p. 166: Example missing?
|     (Search for "self-nest"). (Immediately after missing example:)
|     Shouldn't "a LG" be "an LG"?

Yes, the example is missing. Amazing that no-one hasn't noticed
before! I will try to find one. &winita;

I've made it "an" <lg> ("ell-gee") rather than "a <lg> ("linegroup")

|
|*   6.11.1 Core Tags for Verse, last example, spans pp 165 & 166:
|     Since I don't know what the declaration for LG reads, if it's the
|     same as in P4beta, the value of part= on LG must be upper case.

Yes.

|
|*   6.11.2 Core Tags for Drama, 2nd example, spans pp 167 & 168:
|     -   values of part= of L need to be upper case

Yes

|     -   missing space between "thanks." and "'Tis"

OK

|     -   especially since the last L element is part=I, it is
|         important to put an elipses in before the end-DIV2 tag.

OK


|
|*   6.11.2 Core Tags for Drama, 1st Quarto example, spans pp 168 & 169:
|     -   If you want to use a less ambiguous value for resp= of ADD,
|         MSMcQ's key is "csperberg.yer".

Ah. In fact, this "ms" is meant to be short for "manuscript"
indicating that there is a manuscript addition in Q1. (cf current
argument on TEI-l about <note>!) I've changed it to "unknown"

|     -   Same as previously: case of part=, non-mixedness of type= of
|         STAGE
OK

|
|*   6.11.2 Core Tags for Drama, early printed example, p. 169: The
|     spaces immediately following the start-P tags rub me the wrong
|     way.

You should get out more. Anyway, they're gone.

|
|*   6.11.2 Core Tags for Drama, last example, spans pp 169 & 170: Is
|     the reader supposed to recognize this as from some famous
|     non-drama? I don't. To look at the encoding it *is* a drama. Some
|     more introductory prose would be a good idea, I bet.

Well, it's from a moderately obscure 19th c novel called "Gryll
Grange" so, no the reader isn't meant to recognise it. I'll put a bit
more into the example when I can find my copy. &winita;

|From nfinke1@cinci.rr.com Wed Oct  3 04:12:49 2001
|Date: Mon, 01 Oct 2001 12:13:45 -0400
|From: Nicholas Finke <nfinke1@cinci.rr.com>
|To: Lou Burnard <lou.burnard@computing-services.oxford.ac.uk>,
|    "Steven J. DeRose" <Steven_DeRose@brown.edu>
|Cc: Syd Bauman <Syd_Bauman@brown.edu>
|Subject: Ch 6.  More
|
|Lou and Steve,
|
|I have finally regained connectivity with the rest of the world and can send
|you the remainder of my comments on Ch. 6.  I have reviewed my comments
|against Syd's list and tried to remove any duplication.
|
|I realize that these are extremely late, but I'm going to send them anyway.
|
|Nick
|
|____________________________________
|
|Another general comment:
|
|I find the indentation at the left margins of the examples to be poorly
|done.  
|

Me too. I'm fixing them as I find them

|In some examples (e.g., the <biblStruct> example at the top of page 157) the
|nesting of the elements is nicely conveyed by the indentation.  Text that
|runs over to the next line uses a hanging indent (although the element
|carried by <title level="m"> is treated inconsistently; it should indent
|from the earlier <title>.
|In most places text that runs over is allowed to go all the way to the left
|margin (an example, there are many, can be found at the bottom of 138.
|Also, sometimes nested elements are indented with enclosed elements
|beginning a new line, other times not.   I am sure that a lot of this has to
|do with working the kinks out of your stylesheets, but it makes the examples
|at times much harder to understand than they need to be.


Agreed.

|
|Page 135:
|
|6.5.3, first example at top of page -- in the second line of the example
|there is a hard return after the <l> tag beginning the second line.  If this
|is meant as the start of nesting, the rest of the example doesn't obey.  I
|can understand that <l> and </l> tags look lonely, but I think a consistent
|style is what is needed.
|
|The remaining examples on this page display similar inconsistencies in
|layout.
|
|Page 136:
|
|6.6, after second paragraph -- The note should be placed at the foot of the
|page.

OK. Tagging error.


|
|6.6, explanation of <ptr> and (on following page) of <ref> -- These two
|elements share the "target" attribute, as well as those that they inherit
|from the class <pointer>.  It might be better to indicate this rather than
|repeating the "target" attribute after both elements.

The trouble is that "target" isnt part of the pointer attribute
class. (I can't remember why but there's probably a good/ish reason)
&winita;

|
|Also, I remember that in P3 there is a difference in the "target"
|arrangements for <ptr> and <ref> on the one side and <xptr> and <xref> on
|the other, because SGML prescribes different regimes for targets depending
|on whether they are inside or outside the document.   It is my understanding
|that XLink and XPointer have changed all this, a fact that might be
|reflected here.   

Yes. &winita;

|
|Page 137:
|
|6.6, examples after the fifth full paragraph on the page.  The <ptr>
|elements should nest correctly rather than coming back to the left margin.

OK

|
|Page 138:
|
|6.6, first paragraph -- the identifiers are in a font size that is too
|large.  Ditto for the attribute/value pairs in the third full paragraph.

Formatting problem, now fixed in stylesheet

|
|6.6, fifth paragraph -- The list of chapters where analytic tools are
|discussed should separate the items with semicolons since commas are used
|within the items.

This is a stylesheet issue. We will probably get rid of the comma in
the cross references.

|
|Page 139:
|
|6.7, example at bottom of page -- The text states that a list need not be in
|list format.  It looks to me as if the example is in list format.  Perhaps
|giving the example source without markup would make the statement a little
|clearer.

I've added the following prose:
   For example, the following is a reasonable encoding of a list which (in
   the original) is simply printed as a single paragraph:

|
|Page 140:
|
|6.7, both Latin vocabulary examples -- Unless the source (which I do not
|know) requires them to be wrongly set forth, the entry for "acerbus" should
|be "acerbus, -a, -um" (rather than "-m").  Also, the entry for "audio"
|should have a hyphen before each of the last 3 principal parts to indicate
|that the text given is added to the stem.  It should read "audi&omacr;,
|-&imacr;re, -&imacr;v&imacr;, -&imacr;tus".  (More consistent nesting would
|make both lists more readable).

OK

|
|Page 141:
|
|6.7, last example on the page, 9th line -- should read "&mdash;"
|

Fixed

|Page 145:
|
|6.9.1, second paragraph, line 2 -- spaces missing before and after emdash.

Fixed (I think)

|
|Page 146:
|
|6.9.1, fourth full paragraph -- This paragraph seems to be focused on SGML
|restrictions.   I notice that the reviewer for 36.6 suggests deleting it.
|Might XML namespaces make this task easier?
|

&winita;

|Page 147:
|
|6.9.2, The example needs to be properly indented.  If this is done the
|reader will be able to see the point of the example without squinting.

OK

|
|Page 148:
|
|6.9.3, just a note.  Is there a reason why the milestone tags are not
|presented in XML style, e.g., "<milestone/>" rather than in SGML style,
|e.g., "<milestone>"?  The examples given are all in XML and there isn't any
|explanation given.  I am sure that this is probably discussed somewhere up
|front, and I don't have the time to check.  I just wanted to mention it.
|

We present examples in XML style throughout. 

|6.9.3, third full paragraph, line 4 -- should be <milestone>, not
|<mileStone>.  Also, in Ch. 35, page 766, in the Note to the example
|<milestone> at lines 3 & 4, the text should read:

Yes

|
|"^ scheme (e.g., chapter heads, poem numbers or
|titles, or speaker attributions in verse drama).  Milestones"
|
|putting a comma after "e.g." and spaces between the full stop and
|"Milestones".
|
|Also, consistent indentation and use of blank lines in the example (along
|the lines of the example at the top of the next page) would make it easier
|to read.
|
|Page 149:
|
|6.9.3 -- The three examples on this page that use the <milestone/> tag
|should be reformatted to show nesting.  Also, even if you don't want to
|indicate structure by nesting, why do some elements have a space before them
|while others do not?

Nasty mess introduced during xmlification...

|
|6.9.3, paragraph 5 -- <mileStone> again.

Fixed

|
|
|Page 152:
|
|6.10.1, first example -- needs to be reformatted to match the second
|example.
|
|Page 153:
|
|6.10.1, first paragraph -- (e.g., 'Baxter, 1983') rather than "such as".


OK

|
|6.10.1, example at bottom of page -- The pagebreak should, if possible, come
|between, not in the middle of, elements.  Here, it would be easier to break
|before "<biblScope>.

formatting/stylesheet problem

|
|Page 154:
|
|6.10.1, formal declaration -- There is an inappropriate break ("ser-") in
|the declaration of the element <biblStruct>.  Perhaps if the text is broken
|before "((note, ^" then the indentation could be corrected.
|

formatting/stylesheet problem


|Page 155:
|
|6.10.2.1, paragraph 3 -- The list of elements here uses a bold serif font as
|opposed to the bold sans-serif that you have adopted throughout the text.  I
|personally like the serifs better, but there should be consistency.

Yes: formatting/stylesheet problem


|
|Page 156:
|
|6.10.2.1, the example -- The indentation of the <biblStruct> tag at the top
|should be corrected.
|
|Also, I have found the use of comments to carry information, e.g., "<!-- In
|-->" and "<-- Rpt. In -->", to be very unsatisfactory.   They will only be
|seen by someone reading the text with the markup (not our goal, I think).
|Since applications typically ignore the content of comments, the information
|they contain is, for all practical purposes, lost.
|
|If the text contained in these comments is in the original, then it should
|probably be presented in something like a <note> (with appropriate typing).
|If it is an editorial addition, a note will also do.  If <note> is not
|appropriate,  we need to find a way other than the use of comments to
|present the text.
|
|Page 157:
|
|6.10.2.2, paragraph 1 -- In the gloss on <respStmt> the text says "where the
|specialized elements for authors, editors, etc. do not suffice or do not
|apply."   The only place where specialized responsibility elements other
|than <author> or <editor> appear is in <biblFull> which is not being
|discussed here.  I would leave out the "etc." and say, "where the
|specialized elements for authors or editors do not suffice or do not apply".


I'm reluctant to change this, because we only have one gloss for
respStmt, which is used in several diferent places.

|
|Page 158:
|
|6.10.2.2, paragraph 3 -- The example needs to be formatted so that the
|runover lines in an element are indented more than the initial line.
|
|Also, it should be specifically noted that this example uses <bibl> and not
|<biblStruct> which allows the freedom to tag some items and not others (in
|this case, the authors).
|

I'm not sure which is "this" example. It can't be the same as the one
in para 3, since that uses <biblStruct> so I assume you mean the
hedgehog one to which I've added:

"Note that this uses the more flexible
<gi>bibl</gi>, rather than the structured <gi>biblStruct</gi>
element: consequently, there is no requirement to tag all the
components of the reference (notably the authors)."
 

|Similarly, in the next example, you should mention that it is the use of the
|<bibl> element that permits the use of punctuation between the elements.  If
|<biblStruct> were used, the punctuation would have to be inferred from the
|element structure.  You might want to refer back to the discussion in the
|last paragraph of 10.2.1, or perhaps expand that discussion to emphasize
|this difference between the two elements.

Have added 

"Again, it is only because this example uses <gi>bibl</gi> rather than
<gi>biblStruct</gi>, that specific punctuation may be included between
the component elements of the reference."

|Also, the text in footnote 24 needs to be brought up to be with its
|reference number.

OK. (Actually a stylesheet problem!)

|
|Page 159:
|
|6.10.2.2, paragraph 4 -- the <biblStruct> example.  It seems odd to me that
|the  <resp> element allows #PCDATA while the <respStmt> does not.  I realize
|that <respStmt> is more structured, but, as I mentioned earlier, to put the
|"und" into a comment risks losing it as far as rendering applications go.
|

<resp> does something different: it specifies the nature of the
responsibility being asserted.

|If the position is that the "und" can be easily supplied, there is a need
|for a LANG attribute on this particular <biblStruct> so that the software
|doesn't insert an "and".
|

Yes. I have put a lang attribute. And deleted the UND,

|Page 162:
|
|6.10.2.3 -- In all 3 examples on this page a comment  <!-- in --> is placed
|between the <analytic> and the <monogr> elements.  In addition to my earlier
|comments along this line, it seems to me that in this case the comments are
|completely unnecessary.  In a <biblStruct> the use of these two elements in
|sequence would seem to be to indicate precisely that the <analytic> is
|published in the <monogr>, the information the comment is designed to
|convey.

These examples started life as untagged examples, to
which markup was added and any remaining prose turned ionto comments,
but you're right. The <!-- in -->s are now out.

|
|Page 168:
|
|6.11.2, 2nd example -- I haven't checked the First Quarto, but does
|Francisco's first line begin "STand: " or is it "Stand: "?
|

Actually, yes, it does. The S is an ornamental capital, and the T is a
regular capital.