From lou@ermine.ox.ac.uk Wed Sep 19 18:19:24 2001
Date: Wed, 19 Sep 2001 18:05:12 +0100 (BST)
From: Lou Burnard <lou@ermine.ox.ac.uk>
Reply-To: lou.burnard@oucs.ox.ac.uk
To: M. J. Driscoll <mjd@hum.ku.dk>
Cc: steven_derose@brown.edu
Subject: Re: Comments on chapter 18

Dear Matthew

Many thanks for your comments on this chapter.

On Tue, 18 Sep 2001, M. J. Driscoll wrote:

> Comments on P4, chapter 18
> 
> General:
> 
> 1. Element names are not distinguished typographically,
> neither in the pdf nor html files.  This I assume is a
> processing problem.
> 

Yes. Now fixed, we believe.


> 2. There is a degree of inconsistency in the use of single and
> double quotes.  My understanding is that all quotes in
> examples of mark-up should be double (unless this is
> syntactically invalid -- which is why, I assume, there are
> single quotes round INCLUDE in parameter entity
> declarations and in the values for TEIform), while those in
> the text itself should be single for things tagged <soCalled>
> and double for things tagged <q>. In section 18.1.5, for
> example, there is the following sentence:
> In the example from William James, first written out by
> James as ^One must have lived longer with this system, to
> appreciate its advantages^ the word ^this^ is first replaced by
> ^such a^ and this is then replaced by ^a^.
> Surely these are all equally quotations and should be treated
> in the same way (in the HTML version, only single quotes
> are used, but the ones around the longer quotation are
> ^smart^, while the others aren^t). There are many examples
> of this.  Similarly, in the same passage, a reference to ^the
> ^overlay^ levels of Joyce^s transcriptions^ - the word
> overlay here is, I assume, a term, rather than a quote, and
> should therefore have single quotes.  Sample attribute values
> sometimes have single and sometimes double quotes (and
> the opening single quotes on ^brown^ and ^pencil^ in the list
> of attributes on <hand> and <handShift> turn the wrong
> way).  The second example of mark-up in section 18.2.3 has
> single quotes, but should presumably have double.  The
> simplest way would be to use one or the other, preferably
> single quotes, throughout.  Finally, there are no quotes on the
> values for id in the in-line examples of <add> and <del> in
> section 18.2.4.  This is an XML no-no.
> 

I suspect that these are all in fact caused by inconsistent tagging in the
underlying source. Thanks for the reminder that we need to check these
more assiduously: I will try to do so. Amusingly, your own message has
suffered from the fact that whatever you used to prepare it has inserted
"intelligent" quotes, which are coming out as control characters...


> 3. An attempt has been made to introduce the so-called
> ^Oxford comma^ before the conjunctions ^and^ and ^or^ in
> lists of three or more, but there are a few cases where these
> ^extra^ commas are lacking, particularly in the sections
> giving information on attributes:
> 	18.1.4: ^author, scribe, annotator[,] or corrector^ (three
> times; the fourth has the extra comma)
> 	18.1.7: ^editor, transcriber[,] or encoder^
> 		^deletion, damage or other cause^
> 		^Gap, Del, Damage, Unclear[,] and Supplied Tags^
> 	18.2.1: ^scribe, writing style, ink[,] or character^
> 	18.2.3: ^letter, word[,] or passage^
> 	18.2.6: ^under, beside[,] or through^
> 
> In 18.2.6 there is a sentence which is of the kind normally
> used to justify the ^Oxford comma^, i.e. where one or more
> of the items listed consists of two words joined with ^and^
> or ^or^: ^they may be solid, dashed, or dotted, doubled or
> tripled, wavy or straight, or a combination...^  Here, I think,
> the comma after ^dashed^ should be removed.

Very well spotted! Thank you.

> 
> 4. There are many places where commas are lacking
> following a title in a cross reference, for example in section
> 18.1.3, the last paragraph, where it says:
> ^If it is desired to express aspects of certainty and
> responsibility for some other aspect of the use of these
> elements, then the mechanisms discussed in chapter 17,
> Certainty and Responsibility[,] should be used. See also
> 18.2.2, Hand, Responsibility, and Certainty Attributes[,] for
> discussion of the issues of certainty and responsibility in the
> context of transcription.^ There should be commas after the
> titles. This sort of thing should be relatively easy to check.

Unfortunately it cannot be done entirely automatically, since we also have
title references like "(section 182.3, Wibble wibble)" where no comma
should be inserted, or cases where the cross ref is at the end of a 
sentence. Maybe we should drop the comma that separates the
number and the title?

> 
> 5. There are a number of superfluous commas (mostly
> before parentheses), e.g.:
> 	fn 55: ^MS O.2.1, (Parkes pl. 16).^
> 	18.1.3: ^the element, (i.e., the correction)^
> 	fn 59: ^MS 310, (Klinkenborg 23).^
> 	18.2.3: ^Wife of Bath^s Prologue, (see 18.1.3 ...)^
> Since a comma should _never_ be placed before an opening
> round bracket, this should be easy enough to check globally.
> 

OK

> Commas should be added in a few places:
> 	18.1.3: following the title ^Memoirs of My Dead Life^
> (but before the footnote)
> 	18.3, first paragraph, following ^identification)^

Done

> 
> 6. Other, more general, comments, in the order in which they
> come:
> 
> a. p. 413, 1st paragraph: Why ^critical^ editions?  Why not
> simply ^text editions^? A ^critical^ edition implies the use of
> more than one witness, whereas this tag set is required for
> simple transcription of a single witness.

That hadn't occurred to me, but you are of course quite right. "Text
editions" sounds a bit wet though. Text now reads "It
is expected that this tag set will also be useful in the
preparation of critical editions, but..."

> 
> b. 2nd paragraph (et passim): I was taught at school that
> ^such as [or e.g.] ... etc.^ was a logical solecism and have
> avoided it ever since. Perhaps the TEI is not worried about
> such things.


No need to be snide. It's an overlooked inelegance, which I will instantly
extirpate.

> 
> c. 3rd paragraph: the phrase ^and problems peculiar to early
> printed materials^ does not fit terribly well here in view of the
> sentence that follows.


Recast paragraph as follows:

<p>It should be noted that this chapter focuses primarily upon
problems associated with the transcription of manuscript materials,
and that consequently problems of codicology other matters peculiar to
early printed materials are not specifically addressed
here. Nevertheless, many of the recommendations presented may ---
mutatis mutandis --- also be applied in the encoding of printed
matter. We are conscious that a great deal of work remains to done in
these areas, and that the encoder will need to take even more
individual responsibility than usual in applying the recommendations
of this chapter in such contexts, but believe that these
recommendations form a good basis for such future work


> 
> d. p. 414, section 18.1, first paragraph: I would emend ^by
> the encoder^ to ^by previous editors and scholars or the
> present editor^.


OK


> 
> e. section 18.1.1, 1st paragraph: the parenthetical
> enumeration of types of sources, ^editions, manuscripts,
> witnesses of any type^, is confusing; what, for example, is
> the distinction between a manuscript and a witness?  Why
> not simply say ^sources of any type^?
> 

OK


> f. p. 415: Why are there no attributes given for <hi>, as there
> are for the others?

Because it has no non-global attributes. This is practice throughout the
Glines. I agree it looks a bit odd here, especially because so many of the
other attribute descriptions are almost identical. Removing the
strangeness will however have to wait for the much needed reorganization
of all these elements (cf discussions about idref/cdata)

> 
> g. p. 416: the descriptions of cert and resp repeat
> information which has just been given.

Yes. The descriptions for cert and resp should be removed from the
earlier list. Unfortunately this is not as simple to do as it may appear,
because of problems with the way the class system is being used.
&winita;

> 
> h. section 18.1.2, 2nd paragraph : ^<expan>per</>,
> <expan>re</>, <expan>n</>^ should be
> <expan>per</expan>, <expan>re</expan>,
> <expan>n</expan>.

Fixed.

> 
> i. 18.1.2, 3rd paragraph: not all signs indicating abbreviations
> are brevigraphs and the word should be replaced by ^sign^.

OK

> 
> j. 18.1.2, final paragraph: using an <app> structure to record
> various expansions is wrong in my view.  It would make far
> more sense to treat such things in a note.

Doesnt it rather depend on the reason for wanting multiple expansions?
I have toned the suggestion down a bit out of deference to your view

<p>If more than one expansion for the same abbreviation is to be
recorded, multiple notes may be supplied. It may also be appropriate
to use the markup for critical apparatus; an example is given in
section <ptr target="TCTR"/>.</p>


> 
> k. section 18.1.3, the first George Moore example: Forgive
> my ignorance, but is one allowed to make elements empty
> which are not so defined (i.e. <sic/>); and even if one is,
> would it not make more sense to have <sic
> corr="we"></sic>, parallelling <corr sic="">we</corr>?
> More importantly, however, the use of <sic> and <corr> to
> supply words inadvertently omitted by the author or scribe is
> wrong in my view, and should not even be given as a
> possibility.  Readers should be instructed to use <supplied>.


<sic/> is syntactically identical to <sic></sic> in XML. However, 
more interestingly, you point to a paragraph which is in my view as
yours just plain wrong and always has been. Rather than have the argument
here, I propose to silently drop the example: &winita;

> 
> l. 18.1.3, p. 418 bottom, the example of <note>: surely
> ^Speculum 40" etc. is a <bibl> and aought to be tagged as
> such.

well, arguably.

> 
> m. p. 419: I think using an <app> structure to give alternative
> corrections within a transcription of a single witness is a
> REALLY BAD IDEA.  In fact I would go as far as to say
> that using an <app> structure to do anything within a
> transcription of a single witness is wrong and should be
> punishable by death, or at least expulsion from the TEI.
> 

This seems a little extreme. How would you propose that this example
should be encoded then? The requirement is to indicate variant readings
found for the given source in different sources, each of which other
reading may potentially have its own corrections, annotations, etc. Isn't
that exactly what the <app> element and its children was invented for? If
you don't agree, what would you propose instead? A special kind of
<note>? I agree that the text glosses over somewhat the possible
complications of introducing a different tagset at this point, but that's
a separate problem. &winita;



> n. p. 421, top: the correct way to refer to this Icelandic
> manuscript is: ^Lbs 1562 4to^, not ^1562 quarto^.


Thanks: fixed

> 
> o. p. 421, the example of <delSpan>: should the attribute not
> be REND, rather than TYPE, cf. previous page, ^<del
> rend="strike-through">?


There is some discussion of the rationale for choosing one or the other of
REND or TYPE on the previous page: so it might reasonably be inferred
that the choice is deliberate. Let's posit that in Lalla Rookh (and its
little known sequel Po Rook) Moore regularly indicates long deletion
either by vertical strike through or by a red side bar depending on
whether the deletion was his idea or his publishers... oh all right, I've
changed it back to rend just to keep you quiet.


p. section 18.1.5: This section begins: ^Substitution
of one > word or phrase for another is perhaps the most common of
> all phenomena requiring special treatment in transcription of
> primary textual sources.^ Exactly; that^s why it requires a
> separate element, say <subst>; see below for more details.
> Regarding the three possibilities for encoding substitutions:
> I am against using <sic> and <corr> for substitutions, since
> they are of an editorial nature.  I have always argued that a
> clear distinction needs to be maintained between the means
> of recording what is physically present in the manuscript
> (substitutions, deletions, additions and so on) and editorial
> changes and comments (<sic> and <corr>).  These means
> exist already, in so far as one has separate tags for each; we
> are only doing our readers a disservice by suggesting that the
> two sets of tags can just as easily be used interchangeably.  I
> am also against using an <app> structure to record
> substitutions for the, I should have thought obvious, reason
> that deletions and additions in a single witness are not
> ^variant readings^, which by definition are taken from other
> sources; doing so means that the same mechanism is used
> for two very distinct things, which I should have thought one
> would want to avoid: what does one do when one has both
> multiple witnesses and substitutions within each witness?
> The only method of the three that I would support is thus the
> second.  The other two may, I suppose, be presented as
> possibilities, but I should like to see stronger argumentation
> than there is at the moment for not using them.
> I have argued elsewhere (my article in LLC 15) for a new
> <subst> element.  The example I gave there was: <subst
> hand="scribe" addplace="marginleft" delrend="overstrike"
> del="flest">n&aelig;rst</subst>; it would perhaps be simpler
> to retain <add> and <del> and group them together with
> <subst>, instead of <app>.  IDs could be put on the
> <subst> or <add> and <del> elements in cases where there
> are sequences of substitutions.  To take the example given
> on p. 424:
> 
> One must have lived longer with
>      <subst>
>         <del id="del1">this</del>
>             <del id="del2">
>                <add id="add1">such a</add>
>             </del>
>             <add id="add2">a</add>
>       </subst>
>    system, to appreciate its advantages.
> 
> or:
> 
> One must have lived longer with
>      <subst id="subst1">
>         <del>this</del>
>         <subst id="subst2"><del><add>such a</add></del>
>             <add>a</add></subst>
>       </subst>
>    system, to appreciate its advantages.
> 
> It^s a thought.

And a good one, which I will flag for discussion. But I'm not sure what to
do about it in the current draft. It seems to me that the current draft
makes a good case for using something like <app>, but your suggestion of
using a different grouping element is by no means a bad one. 

> 
> q. p. 423, centre: shouldn^t ^SGML^ be ^XML^?
> 

Well no, in fact, because this section is describing something specific to
SGML (minimization). Unfortunately, our auto conversion of all examples
from SGML to XML has rather messed up the point of the discussion here
though, so I think I will just delete the (very out of date) discussion 
anyway.


 > r. section 18.1.7: in the descriptions of the attributes of
> <gap> and <supplied> some of the sentences begin with
> upper case letters (^In^ (twice) and ^When^); these should
> be lower case for the sake of consistency.

fixed

> 
> s. 18.1.7: to the definition of <supplied> should be added:
> ^or because, in the estimation of the editor, it has been
> inadvertently omitted^.

I suppose so...

> 
> t. 18.2.1, the attributes of <hand>: I see that the (to me)
> nonsensical FIRST is still here; I wonder if this shouldn^t be
> replaced with SCOPE, with possible values sole | major |
> minor, as we have done in MASTER.

I've retained it for compatibility reasons, but have improved the
description slightly. I agree that the Master version is better.

> u. 18.2.2, first example: the value of RESP is given in the
> first line in lower case, in the second in upper; these should
> be regularised.

Ooops.


> 
> v. 18.2.2, third paragraph: I would write ^Bowers^s^ rather
> than ^Bowers^^, but perhaps TEI house style dictates
> otherwise.

"Bowers's"??? There's a case where *my* English teacher would have had a
fit! 

> 
> w. 18.2.3, first paragraph: ^other sources^ should perhaps
> rather be ^another source or sources^.

added "one or more other sources"

> 
> x. p. 430, middle of page: ^V&ohook;lusp^ should either
> be written with a hooked-o (Unicode 01EB) or ^Vlusp^.

Something very wrong happened in the xmlificn process. Have
fixed. Incidentally you'll be amused to know there's a comment
at the head of the file which reads:

<!-- 94-04-07 : MSM : spell Voluspa correctly (NOT an umlaut!) -->


> 
> y. p. 430, bottom: Instead of ^um aldr
> d<damage><unclear>aga</unclear></damage> yndisniota^
> why not have ^um aldr d<unclear
> reason="damage">aga</unclear> yndisniota^?
> 

Primarily because this section is describing how to use of
the <damage> element, I suppose. But also because <damage> gives you
more options for exaplain e.g. the agent.
I've added the simpler option as an alternative



> z. p. 431, middle (3rd example): ^<gap reason="rubbing"
> extent="4"/>^ should rather be ^<gap reason="illegible"
> reason="rubbing" extent="4"/>^
> 

I assume you you mean "agent=rubbing". That's what I've added anyway.


> aa. section 18.2.5: why is the attribute on <space> indicating
> whether the space is horizontal or vertical called DIM; should
> it not rather be TYPE?

Don't know. There are only two possible values according to the DTD which
seems slightly odd too. But I'm not changing it yet. Axis might be a 
better name than TYPE.



> 
> bb. section 18.2.6, first example: ^<del
> rend="strikethrough">; this was written <del rend="strike-
> through" in section 18.1.4, p. 420.


Well spotted. Fixed.
 
> 
> That^s about it.  I hope these are useful.
> Matthew
> 

Very much so. Thanks!

Lou




