I've now done more work on updating PH, following a set of very helpful comments
from Arianna and others at King's. Details attached.

I'm still waiting on Conal for input about what a surface is though. And I still
haven#'t sorted out the mess which is <hand/Desc/Note> etc. But the rest of this
chapter is now looking quite solid, methinks.


AC]  - "It should be noted that this chapter focuses primarily upon problems
AC] associated with manuscript materials, and that consequently problems of
AC] codicology and other matters peculiar to early printed materials are not
AC] specifically addressed here."
AC] 
AC] I am not sure that 'consequently' is a good word here. Indeed codicology
AC] deals mainly with manuscript materials and the way they are combined. We
AC] could probably say that this chapter aims at facilitating the basic
AC] representation of cultural artifacts in connection with their textual
AC] components rather than dealing with the description of their detailed
AC] physical making and composition.
AC] 

How about 

"It should be noted that, as elsewhere in these Guidelines,  this
chapter places more emphasis on the problems of representing the
textual components of a document than on those relating to the
description of the document's physical characteristics such as the
carrier medium or physical construction. These aspects, of particular
importance in codicology and the bibliographic study of incunables,
are touched on in the chapter on Manuscript Description (<ptr
target="#MS"/>) and also form the subject of ongoing work in the TEI
Physical Bibliography workgroup."

I've also revised the following para, as follows:

<p>Although this chapter discusses manuscript materials more
frequently than other forms of written text, most of the
recommendations presented are equally applicable <foreign>mutatis
mutandis</foreign> in the encoding of printed matter or indeed any
form of written source, including monumental inscriptions. Similarly,
where in the following descriptions terms such as
<soCalled>scribe</soCalled>, <soCalled>author</soCalled>,
<soCalled>editor</soCalled>, <soCalled>annotator</soCalled> or
<soCalled>corrector</soCalled> are used, these may be re-interpreted
in terms more appropriate to the medium being transcribed. In printed
material, for example, the <soCalled>compositor</soCalled> plays a
role analogous to the <soCalled>scribe</soCalled>, while in an
authorial manuscript, the author and the scribe are the same person.
</p>


AC] 
AC] - trancribed --> trascribed
AC] 

Ooops!


AC] - "The grid point <hi rend=3D"math">a b</hi> is understood to be
AC] the point which is located a points from the origin along the <hi
AC] rend=3D"math">x</hi>
AC] (horizontal) axis, and <hi rend=3D"math">b</hi> points from the origin
AC] along the <hi rend=3D"math">y</hi> (vertical)
AC] axis"
AC] 
AC] should be
AC] 
AC] "The grid point <hi rend=3D"math">a b</hi> is understood to be
AC] the point which is located <hi rend=3D"math">a</hi> points from the origi=
AC] n
AC] along the <hi rend=3D"math">x</hi>
AC] (horizontal) axis, and <hi rend=3D"math">b</hi> points from the origin
AC] along the <hi rend=3D"math">y</hi> (vertical)
AC] axis"

Indeed it should. And now does.


AC] 
AC] By the way <hi rend=3D"math"> doesn't seem to be rendered anyway different
AC] from the main text, which doesn't help readability in this case.

One for James/Dot!


AC] 
AC] I think some people may understand better this note and the concept
AC] behind it whit the help of an image of a grid superimposed on a figure.
AC] 

A figure inside the footnote? I hope you don't mean that. I suppose a
figure in the text might be useful, but it might look as if we were
trying to teach is fairly elementary geometry. The footnote is just
there as an aide memoire for those (like me) whose memory of O-level
maths is starting to fade...


AC] - "more delicate grid"
AC] 
AC] do you mean more granular here?

Well, to be exact I mean "a grid of more delicate granularity", but
that's a bit of a mouthful!

AC] 
AC] - "Since this image contains more than one page however, and has not
AC] been cropped, it might be better to define two distinct surfaces, one
AC] for each page."
AC] 
AC] I would add "...one for each page, including the illuminated margins" to
AC] make clear that we are not considering the writing frame only as cropped
AC] section.
AC] 

have added ", including its illuminated margins" before the
fullstop. But note that this may need further revision if Conal
persuades us that "surface" means something different.


AC] - either I am not understanding how this works or there is something
AC] wrong here:
AC] 
AC] <facsimile>
AC]    <surface xMax=3D"500" yMax=3D"321" box=3D"50 20 210 180">
AC] <!-- left hand page -->
AC]     <graphic
AC] 
AC] url=3D"http://commons.wikimedia.org/wiki/Image:Handschrift.karlsruhe.blb.=
AC] jpg"/>
AC]    </surface>
AC]    <surface xMax=3D"500" yMax=3D"321" box=3D"240 25 400 280">
AC] <!-- right hand page -->
AC]     <graphic
AC] 
AC] url=3D"http://commons.wikimedia.org/wiki/Image:Handschrift.karlsruhe.blb.=
AC] jpg"/>
AC]    </surface>
AC]   </facsimile>
AC] 
AC] The coordinates of the left hand page are not well defined. The
AC] second couple of coordinates is wrong. It should be something like 220
AC] 280 instead; same in the example that follows where otherwise the
AC] writing frame wouldn't be included in the coordinates of the surface.
AC] 

You are right. This is a typo. Should be 50 20 210 280.



AC] I am not dealing here with the meaning of <surface> (I believe we can
AC] express our preferences once Conal has drafted his proposal).
AC] 

yes.


AC] - written part --> writing frame
AC] 

Hmm, is this a technical term? I havent come across it before (and am
not online so cannot check) I've changed it to "written area" for the
moment. And note that we are not talking about the area actually
marked for writing in in the original (e.g. by pricking); it includes
margins etc.



AC] - "Since all <zone> elements use the same co-ordinate system (that
AC] defined by their parent <surface>," --> missing closing round bracket
AC] 

Fixed


AC] - what about having @facsRef when the attribute points to a <graphic>
AC] element -and only @facs when it points to another type of URI (e.g.=20
AC] image)-; we could then have @textRef instead of @start, which, to be=20
AC] honest, I don't like very much.
AC] 

I'm a bit reluctant to add yet more attributes, to tell the truth. We
have lots of URI attributes, and only in a few cases do we try to express any
constraint on what they can point to, even fewer where we go to the
lengths of providing two different attributes to do the same thing but
with different names depending on how you reach the desired target. The @facs
attribute
points to an image. Sometimes you find the image via a proper
<facsimile> element, which is our recommendation; sometimes you find
it floating about in cyberspace. I think that's a reasonable
compromise between ease of processing and ease of encoding.  

I'm not crazy about @start myself. But it needs to make explicit that
you are not necessarily pointing to all and only the text depicted by
the image: so the name is chosen to indicate that at least the "start"
of the image (whatever that means) and the start of the text are
aligned.



AC] - "In many cases the glyph found in the manuscript source also exists
AC] in the Unicode character set: for example <!-- ? -->."
AC] 
AC] You could use the following:
AC] MUFI entity: &et;
AC] Code point (Unicode): 204A
AC] Junicode: F143
AC] Unicode descriptive name: TIRONIAN SIGN ET
AC] MUFI descriptive name: LATIN ABBREVIATION SIGN ET
AC] 

Beautiful example, just what I wanted!

Have now inserted 
"<p>In many cases the glyph found in the manuscript source also exists
in the Unicode character set: for example the common Latin brevigraph
&#x204a;, standing for <mentioned>et</mentioned> and often known as
the <soCalled>Tironian et</soCalled> can be directly represented in
any XML document as the Unicode character with code point
<val>x204A</val> (see further <ptr target="#SG-er"/> and <ptr
target="#CHSH"/>). " before "In cases where it does not..."

AC] - I think the proposal with expan/ex is great! [I asked Elena's opinion
AC] as well and she seems very satisfied by this]. My only doubt is about
AC] nesting. Indeed both <ex> and <expand> seem to have the possibility to=20
AC] self nest. Has this been done on purpose?
AC] 

Well,  <ex> (and <am>) cannot self nest. It's true that <expan> and
<abbr> can though. The problem is both defining a content model to preclude
this or coming up with a good reason why you might not want to. Some
mad person will always want to treat e.g. USAF as two abbreviations
("US" and "AF"), and hence producing two nested expansions ("United
States" and "Air Force").... it's the TEI Way. (trademark)


AC] - "In the general case, encoding this is best done using the mechanisms
AC] described in the module for textual criticism described in chapter 24.2
AC] Personalization and Customization."
AC] 
AC] I think here you probably wanted to link to the Critical Apparatus
AC] chapter instead.

Ooops. yes. That sentence is a bit wordy too. 


AC] 
AC] - "This encoding asserts that the reading wyf found in Gg is regarded as
AC] a correction by Parkes."
AC] 
AC] I am not sure about this example where @resp is within <corr> in a
AC] <rdg>. I understand it, but I think in general an editor would use the
AC] <lem> element, wouldn't he? it is true that <lem> can occur only once in
AC] an <app> and therefore it would be difficult to express multiple
AC] responsibilities on different corrections as this examples shows, but in
AC] general to use a single reading to make a new edition you would use
AC] <lem>.
AC] 

It seems strange to me too, because elsewhere we use  <corr>
only for things that are not witnessed at all, whereas here it means
"not witnessed in the source being encoded". I am agnostic on whether
or not to keep this discussion; removing it is quite a big change
though.



AC] - "If no other source is indicated (either by the source attribute, or
AC] by the wit attribute of a parent <rdg>), the reading supplied within a
AC] <corr> has been provided by the person indicated by the resp attribute."
AC] 
AC] As above I understand this, but the meaning of <rdg> is a bit stretched
AC] here, since it is not a variant witnessed in a source we are talking
AC] about in this case, but rather what is normally considered in these
AC] guidelines as a 'supplied' string.

But it is witnessed, surely? It's in Gg. The encoding is saying  (a)
there is a different reading at this point in a certain ms and (b)
Parkes thinks that this different reading should be used to correct
the others. 


AC] 
AC] - <hand xml:id=3D"mb" scribe=3D"Max Beerbohm holograph"/>
AC] 
AC] if <hand> will get the same attributes of the current <handNote>, this
AC] should be:
AC] 
AC] <hand xml:id=3D"mb" scribe=3D"#Max_Beerbohm scope=3D"sole"/>
AC] 

This loses the fact that Max is the author as well as the writer,
doesn't it? But you're right that the attribute value should not be a
string of words

AC] or even better
AC] <hand xml:id=3D"mb" scribe=3D"#Max_Beerbohm scope=3D"sole">
AC]   <handNote>This manuscript is an holograph by Max Beerbohm</handNote>
AC] </hand>
AC] 
AC] Whatever happens with the attributes of <hand>, the @scribe value should
AC] still be a pointer, according to the specs.
AC] Same is valid for <hand xml:id=3D"dhl" scribe=3D"holograph"/> in the exam=
AC] ple
AC] that follows.

Yes. These attributes will need some fiddling when we work out what to
do with hands...


AC] 
AC] - "If deletions are classified systematically, the type attribute may be
AC] useful to indicate the classification; when they are classified by the
AC] manner in which they were effected, or by their appearance, however,
AC] this will lead to a certain arbitrariness in deciding whether to use the
AC] type or the rend attribute to hold the information."
AC] 
AC] But att.tracsriptional doesn't include @type (while
AC] att.authorialIntervention used to include it). If, as I believe the P5
AC] practice is, @type should not be included within existing classes, I
AC] think att.typed should be added to <add>, <addSpan/>, <del>, <delSpan/>.
AC] So also in the examples of the use of <addSpan/> that follow, @n should=20
AC] be substituted by @type, in my opinion.

I have added add, addSpan, del, delSpan to att.typed

AC] 
AC] - <hand xml:id=3D"heol" n=3D"Helgi =C3=93lafsson"/>
AC] 
AC] Why is @n used instead of @scribe here?

No idea. I#'ve changed it to scribe for now. Do you think @scribe
should be analogous to @key or to @ref ?



AC] 
AC] - I wander whether <subst> should be allowed to selfnest as <choice>
AC] does. In any case, I think this element is a good and useful addition in=20
AC] this chapter.

Some of these elements are members of model.pPart.transcriptional and some
are members of  model.pPart.editorial -- the latter indicating a
greater  degree of editorial intervention than the former. The content
model for subst includes only members of the former, which maybe needs
rethinking. Not sure. 

AC] We could also add in the prose that when the sequence of authorial=20
AC] intervention in a manuscript cannot be determined with certainty=20
AC] (subjective time) the @resp and @cert attributes should be used within=20
AC] <subst>.
AC] 

Not sure what you are implying here? 

AC] - I understand the example with @varSeq, but in general I think @varSeq
AC] should be used to express dependency between variants found in different
AC] witnesses as the specs say, rather than for tracking the genesis of
AC] authorial manuscripts (where @seq should be used instead).
AC] 

This is another occasion where I am simply preserving what was
originally proposed by the chapter without really thinking it is a
good idea. Maybe this possibility should be explicitly removed, or at
least clearly distinguished? 

AC] - shouldn't <restore> belong to att.trascriptional plus att.typed
AC] instead of having its own set of attributes? I think @means could be
AC] expressed by using @rend and/or @type.
AC] 

Yes. Now done.


AC] - "The value of the hand attribute should be one of the hand identifiers
AC] declared in the document header (see section 14.4.1 Document Hands)."
AC] 
AC] If we keep two different ways of documenting hands (as described in the=20
AC] Critical apparatus and in the MS chapters), this reference needs to link=20
AC] to both sections, especially considering that the MS approach is more=20
AC] accurate.
AC] 


This is a big IF however. 


AC] - <corr><ex> and <supplied> --> <corr>, <ex> and <supplied>
AC] 

OK


AC] - machine-readable --> electronic? digital?
AC] 

no need for any of these words I think: have removed m-r anyway.


AC] - should <note> and <abbr> be member of att.typed instead of having=20
AC] @type? You could still suggest values for the use of the attribute in a=20
AC] specific element, couldn't you?

This is a generic problem throughout P5. Last time I looked, about
half the uses of @type were specifically defined and half
inherited. It's probably time to review that now, as a lot has changed
since the last set of class system updates.

AC] 
AC] - <gap reason=3D"illegible" agent=3D"rubbing" extent=3D"4"/> --> I would =
AC] also=20
AC] add @unit=3D"letter"
AC] 

Done.


AC] - I wander whether @extent, @hand, @agent and @unit could be all part of
AC] att.damaging (or different class name), so that both <gap> and <damage>
AC] could be members of this class. We could then add @reason to <gap> and
AC] @degree and @group to <damage>.
AC] <unclear> could also become member of att.damaging with the addition of=20
AC]   @reason.
AC] In any case, I would add @unit to <damage>.
AC] 

Looks good. I will investigate.


AC] - <anchor xml:id=3D"washOout"/> --> <anchor xml:id=3D"washOut"/>
AC] 

Clearly a Scottish scribe took over at this point.


AC] - "The rules for combinations of the <add> and <del> elements, and for
AC] the interpretation of such combinations, are similar:"
AC] 
AC] I think that after this section something should be said about the new
AC] @seq element that allows to disambiguate the sequence of interventions.

OK: how's this.


AC] 
AC] - "Methods for recording page breaks, column breaks, and line breaks in
AC] the source are described in section 3.6 Simple Links and Cross References=
AC] ."
AC] 
AC] Shouldn't this point to the Milestone Tags section instead?

Yes. I didn't check the link: it was wrong.

AC] 
AC] - "The <note> element allows us to record that the scribe wrote nota,
AC] but is not well-adapted to show that the nota points both at all four
AC] lines and at two pairs of lines within the four lines."
AC] 
AC] Well...these are the cases where we can say that the digital facsimile
AC] elements facilitate representation even if they privilege an image-based
AC] approach. I assume the physical bibliography chapter will cope, as
AC] far as the text-base approach can deal with this, with this sort of=20
AC] encoding in the future.
AC] 

OK, how's this:

<p>At the lowest level, all such features could be captured by use of
the <gi>note</gi> element, containing a prose description of the
manuscript at this point, enhanced by a link to a visual
representation (or facsimile) of the feature in question.  
Markup languages in general are limited in their abilities to describe
all possible features of layout or realization.  For example,...


AC] However, towards the end, when it says " Some of these issues may be
AC] covered in future editions of these guidelines."
AC] 
AC] we could add that the MS chapter deals with some of these features.

Yes: now reads

As noted above, many of these features may be encoded using the
elements provided by the module
for  manuscript description documented in <ptr target="#MS"/>. 


AC] 
AC] - again, shouldn't <fw> be member of att.typed?

Why should it? I suspect you of being a secret member of FTG (the Front for
Type Globalization).


AC] 
AC] - I wander whether <floatingText> should be mentioned in this chapter.
AC] 

Well it could be, but so could any number of other things e.g. <div>
<head> <p>... or do you think it is particularly important in
transcription? 


AC] - I think I agree with Matthew that <unclear> is a bit redundant and=20
AC] <supplied> should be used instead eventually in combination with=20
AC] <damage> or detailed values for @reason.
AC] 

I beg to differ. <unclear> encloses text that is (you think, but
you're not sure) present in the source. <supplied> encloses text that
you know is not there, but ewhich you think should be.

I agree that the distinction between <unclear> and <damage> is pretty
vague though: is that what you meant?



AC] Arianna
AC] 
AC] P.S. I finished reading the chapter last night, but just saw you have=20
AC] added <am> today. I think it's good to have an element to enclose the=20
AC] abbreviation sign; although some may complain for the proliferation.
AC] 

It's not only to enclose abbreviation signs of course: probably a
better exmaple is needed to make this clearer.