[tei-council] genetic draft -- from Brett, pt. 4

Tue Aug 30 01:16:06 EDT 2011

Definitely not! Even if Lou is heavily working on this at present. I guess a couple of us are lurking through your notes to grasp the main trends.
Laurent

Le 29 août 2011 à 22:22, Brett Barney a écrit :

> 
> I suspect that I should really just be sending these to Lou and not junking
> everyone else's inboxes. So that's what I'll plan to do in the future,
> unless someone objects.
> 
> Best regards,
> Brett
> 
> 
>> The @spanTo may be used to indicate the end
> 
> Should read "The @spanTo attribute may be used to indicate the end"
> 
> So <mod> can be either empty or not. Hmmm. Is there a reason for using a
> different approach here than with <add> and <del>? That is, why don't we
> have
> two new elements, <mod> and <modSpan>? Alternatively, why don't we get rid
> of
> <addSpan> and <delSpan> in favor of <add spanTo> and <del spanTo>?
> 
> The camel-casing of <metaMark> is contrary to the rule implicit in other
> camel-cased element names, I think. To remember whether an element is
> camel-cased, I've always relied on a rule that goes something like "When
> two
> stand-alone words (or their abbreviations) are combined, the second begins
> with a capital." As "meta" isn't a word on its own, shouldn't the element
> name be all lower-case? At the very least, the prose should be consistent;
> it's currently spelled "metamark," "meta-mark," and "metaMark" in various
> passages.
> 
> The prose description of metamark makes good use of a distinction between
> "text" and "document," but the <desc> of the element uses "text" for both
> senses. Worse, it says that metamarks can be "textual" or "graphical,"
> effectively cutting the pie yet another way.
> 
>> Unlike marginal notes or other additions to the text, meta-marks are used
> by
>> the writer to indicate a deliberate alteration of the writing itself,
> such as
>> ʻmove this passage over thereʼ.
> 
> Two things: 1) I don't see how one can claim that "additions to the text"
> don't "indicate a deliberate alteration of the writing itself"; 2) plenty
> of
> marginal notes say things like "move this passage over there," so I don't
> understand what distinction this bit is trying to shed light on.
> 
>> A metamark may contain text, or some other graphic which the encoder
> wishes
>> to preserve,
> 
> Should this be ". . . . which the encoder wishes to represent"? [I'm taking
> issue, I guess, with the implication that transcription and/or encoding
> preserve or destroy what's on the manuscript.]
> 
> I'm a *tiny* bit bothered by the lack of parallelism in the list of sample
> values for @function. Namely, "used" is not like the others.
> 
>> The passage to which the metamark applies may be indicated in either of
> two
>> ways:
> 
> Without some sort of indication that the two methods cover different cases,
> I
> don't like having two ways of doing the same thing. I can see that @spanTo
> couldn't accommodate teh example, but I'm not sure why @target couldn't
> work
> for everything. If indeed both are needed for different cases, I think
> readers will appreciate something explicit about what the differences are.
> 
> Further against @spanTo here, I'm uneasy that it means something different
> on
> this element than it did on <mod>; here, it's not indicating the end of the
> current element but the end of the current element's referent.
> 
>> A further sentence was then added, while at some later stage the text and
>> also the metamark were deleted.
> 
> I'm unsure whether it was added to the text or to the metmark. Upon close
> examination, I see that it's the former, in which case it dosen't seem
> pertinent information, except to explain bits that show in the image. But
> what about the multiple hash deletion marks or the other marginal tidbit
> (the
> one preceded by the cross mark)?
> 
> I was a little bit surprised to the <lb>s in the example's <ab>.
> 
>> in section 1.4
> 
> Should presumably read, for now, "in section ??"
> 
>> Such cases should be distinguished from cases where the writer does not
>> intend to suppress the content
> 
> I don't know why "should." I'm accustomed to statements that are less
> jugdmental and more context-aware: "If it is thought that blah blah blah,
> one
> can etc. etc., but if instead it is thought that yakkity yak, one can this
> &
> that."
> 
>> but these should be distinguished from the ʻdeletionʼ signalled by the
> large
>> cross,
> 
> 2 things: 1) Here and in the next two paragraphs "cross" is used where I'd
> have expected something like "X." Just checking that you really do mean to
> say "cross." 2) If the whole point rests on the notion that this is
> different
> from a deletion, I hope there's a way to avoid describing it as one, even
> surrounded by quote marks. What about something like "but these are
> semantically different from the large cross/X/intersecting basically
> straight
> lines, . . . "?
> 
>> instead the status of existing material changes
> 
> I think I see the meaning here, but I suspect that many will not. It might
> easily be argued, in fact, that retracing is done precisely to *not* change
> the status of the existing material.
> 
>> which is subsequently fixed,
> 
> At least where I am, "fixed" is seldom used in the sense intended here, and
> the most common sense of the word is unfortunately almost opposite what's
> intended. What about "confirmed" or something similar? If pressed I could
> even make the case that "fixed" isn't really the right word anyway, since
> one
> can imagine cases in which the second act of inscription uses a more
> ephemeral (but possibly brighter or bolder, etc.) medium.
> 
>> its @cause attribute may be used to distinguish them.
> 
> I have an ominous feeling that I may be unwittingly stepping into a
> minefield, but here goes. Why not @reason?
> 
>> we can distinguish at least two attempts
> 
> I think this should read "we can distinguish at least *three* attempts"
> 
>> When metamarks and other markup-like strokes are inked over with the same
>> purpose as the fixation or clarification of text passages, the redo
> element
>> described in the next section should be used in preference.
> 
> I'm not following this. In any case, it seems to contradict the definition
> given for <redo>: "points to a marked-up intervention in a text which has
> subsequently been marked for a second time *in a different way.*" Wait. I
> think I get it, now that I look at the Faust example. "in a different way"
> is
> definitely misleading, I think. And so is "with the same purpose as the
> fixation or clarification of text passages." How about just "When metamarks
> are retraced, the redo element described in the next section should be used
> in preference"?
> 
>> The element restore (??)
> 
> Not sure what the question marks here signify. Is the idea that maybe we
> don't want/need <restore> at all?
> 
>> <line>This is <del layer="#s2" rend="overstrike"> <undo spanTo="#Xa"
>> rend="dotted" layer="#s3"/>just some <anchor xml:id="Xa"/> sample <undo
>> spanTo="#Xb" rend="dotted" layer="#s3"/>text, <anchor xml:id="Xb"/> we
>> need</del> <add layer="#s2">not</add> a real example.</line>
> 
> Hmmm. OK, I know that this isn't the example you want to go to press with,
> but it seems to make problematic the way <undo> and its attributes are
> described a little earlier. Specifically, the <undo>s here don't actually
> "point to the marked-up intervention," at least not in any way that the
> that
> I was expecting from the definitions. In the example, there aren't any
> @target attributes at all; it would seem that the logic for knowing what's
> being undone depends on parent/child relationships, right? But that isn't
> ever explained. A bigger concern, which I'm just not smart enough right now
> to try to answer, is whether that's even a water-tight system. Will it
> always
> be the parent that "names" the intervention?
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> 
> PLEASE NOTE: postings to this list are publicly archived

Laurent Romary
INRIA & HUB-IDSL
laurent.romary at inria.fr