[tei-council] handShift anomaly

[M. J. Driscoll]

For what it's worth my understanding of <handShift> was that it marked just 
that, a shift from one scribal hand to another, in which case one needed to 
indicate both the old and the new hand. One did not, in other words, begin 
one's text with a <handShift> element identifying the first hand and then use 
another one when a new hand took over (in which case @old would be 
superfluous).  Mind you, doing so would make more sense, but then the name of 
the element should probably be something other than <handShift> (even as people 
tend to find it counter-intuitive to begin the first line of a text with a line-
break).

I might also add that I've always thought it was really silly to use 
<handShift> to indicate a shift in things other than identity of the scribal 
hand, e.g. the colour of the ink. All that kind of stuff can be dealt with in 
<handDesc>.

Matthew

> Dear Lou (cc Council),
> 
> I agree that making these attributes optional is better than making them 
> required, but:
> 
> 1) I don't see the point of allowing @old, which seems to add no 
> information that cannot be encoded otherwise (as you note). More 
> importantly, though, it creates the opportunity for:
> 
> ...<handShift old="a" new="b"/>blah blah blah<handShift old="x" 
> new="c"/>blah blah ...
> 
> That is, being able to comment on the hand both before and after the 
> shift creates the opportunity to do this incompatibly. Would it not be 
> safer to allow only the description of the new hand?
> 
> Note that allowing both @old and @new also creates the opportunity for 
> markup like:
> 
> ...<handShift old="a"/>blah blah<handShift old="b" new="c"/>blah 
> blah<handShift new="d"/>blah blah ...
> 
> That is, allowing both @old and @new invites users to be inconsistent 
> about where they describe their hands, even when they describe them all. 
> This complicates processing and does not appear to convey any 
> compensatory informational advantage.
> 
> Unless there is an informational advantage to allowing both @old and 
> @new that I have failed to perceive, it seems that permitting only @new 
> would prevent both errors (conflicting descriptions) and inconsistencies 
> (which complicate downstream processing), and would do so at no added cost.
> 
> 2) I'm a bit uneasy about (although not entirely opposed to) allowing 
> both embedded descriptions (<handShift><desc>blah 
> blah</desc></handShift>) and remote ones (<handShift new="#blah"/>). On 
> the minus side, this seems to create the opportunity for conflict and 
> inconsistency (in the presence of both, the embedded description might 
> conflict with the remote one; some descriptions in a single file might 
> be embedded and others remote, which complicates processing and provides 
> no clear informational advantage). Additionally, if we allow 
> <handShift/> to describe both preceding and following hands, the 
> proposed model (<handShift><desc>blah blah</desc></handShift>) doesn't 
> seem to provide any formal marker of whether the <desc> applies to the 
> old or the new hand. On the plus side, references that occur only once 
> (which will often be the case with hands) might be more legible (that 
> is, more convenient for the encoders) when they are embedded, while 
> those that may occur more than once (as happens with manuscripts where 
> parts A and C are by one scribe and part B by another, which I've 
> encountered) might be more appropriately encoded remotely (so that the 
> same information need not be entered more than once). I don't have a 
> strong opinion about which way to go on this.
> 
> One other (nit-picking) objection (since you asked) is that when I read 
> your posting, I had to look up what "PH" means, and when I went to the 
> P5 link on the TEI web site (as most users would do) in an attempt to 
> discover this, I had to hover over every chapter link and look at the 
> resulting URL in my status bar to figure out that PH means 
> "Transcription of Primary Sources," which is about as non-mnemonic as 
> one can be. Didn't Council recently agree to rename the chapters?
> 
> Best,
> 
> David
> 
> Lou's Laptop wrote:
> > This came up in discussion with an attendee of the TEI workshop last 
> > week ...
> >
> > According to the text of PH, the attributes @new and @old are optional 
> > on handShift. However, according to the schema, both (!) are required.
> >
> > I propose to change the schema to match the documentation (rather than 
> > the other way round). I also propose to allow <handShift> , currently 
> > empty, to contain a <desc> element.
> >
> > This means that an encoder can choose from the following spectrum:
> >
> > 1. Just mark the change of hand
> >     <handshift/>
> > 2. Provide a bit of description
> >     <handShift><desc>starts using green ink</desc></handShift>
> > 3. Point to a more detailed discussion of the new hand
> >    <handShift new="#greenInk"/> (somewhere else there will be  a 
> > <handDesc xml:id="greenInk">)
> > 4. Point to a more detailed discussion of both previous and new hands 
> > (? why you'd want to do this I cannot imagine, but still)
> >    <handShift new="#greenInk" old="#typeScript"/>
> > 5. Modify the information conveyed by the pointer
> >   <handShift new="#greenInk">
> >      <desc>a slightly darker shade than used elsewhere</desc>
> >  </handShift>
> >
> >
> > Any objections?
> >
> >
> > for <desc> read "member of model.descLike", of course.
> >
> >
> > _______________________________________________
> > tei-council mailing list
> > tei-council at lists.village.Virginia.EDU
> > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> 
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council