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

[Lou Burnard]

[just so they don't get lost, here are my reactions to the specifics in 
Brett's note #2]

On 24/08/11 21:32, Brett Barney wrote:
>
>> 6. discussion of spanTo needs expansion. Some more real examples would
>> help.
>
> I don't know that I can help with expansion of the prose, but I'll spend
> some time looking for other examples. Is there a particular sort that would
> be especially welcome?


Any sort of example would be welcome. FWIW, I am assuming that we are 
all agreed on the principles already stated about how @spanTo is meant 
to work, and further that
a) the existing xxxSpan elements (addSpan and delSpan) are to be 
deprecated in favour of a version of xxx which behaves in the same way 
as other members of the spanning class.
b) in particular, an element which is a member of att.spanning *must* be 
empty if it supplies a value for @spanTo

>
>> 7. Should<metaMark>  possibly have a<desc>  child to describe it rather
>> than relying on brief characterisation as attribute values?
>
> Yes. I know, we should try to generate one, then.

So where would the content of the metamark go?

>
> --------------
>
>> The element patch is useful in cases where the written surfaces
>> constituting a document are not homogeneous.
>
> I don't think this description of the cases in which patch is useful is
> quite right. Many manuscripts comprise multiple leaves that are not all
> "homogeneous" (e.g., one torn from a notebook, others written on the backs
> of envelopes, etc.), but I don't think those manuscripts are the sort
> meant. Perhaps something along the lines of "The element patch is useful in
> cases where an inscribed leaf subsumes one or more physically distinct
> scraps."

instead of "homogenous", how about "where some or all of the written 
surfaces are composed of physically distinct scraps"

>
>> Most writing is linear, in the sense that it is composed of discrete
>> tokens organized physically into groups, typically organized in a
>> sequence corresponding with the way they are intended to be read.
>
> This sentence seems to me to waffle unnecessarily--e.g., I don't see a
> reason for both qualifiers "mostly" and "typically." More important,
> though, I think that the last two-thirds ("organized . . . to be read."),
> is more opaque than "linear," for which it's presumably a gloss. Most
> important, though: The observation that most writing is linear doesn't by
> itself constitute to my mind an argument that we need an "element to hold a
> complete group of such tokens." I'd be much more convinced by the sort of
> reasoning, common elsewhere in the Guidelines, that having the contents
> marked up in this way allows something that people want to do.

Sorry, but I disagree. This sentence reminds you that writing is mostly 
linear -- it is meant to be read in a given sequence. Not always, 
because we have palindromes. The writing on a document is organized 
sequentially to reflect how it is meant to be read -- but not always 
because we have acrostics. Having a container for sequences of writing 
is therefore useful because it allows you to do what you want to do, 
i.e. read the stuff in the way it was meant to be read. But maybe others 
wish to chime in on this stylistic issue?


>
>> Where, however, the lineation is not considered useful or significant,
>
> Small point: I'd prefer just "significant" to "useful or significant." Or
> maybe "purposeful or significant."

OK, removed "useful or". Also revised this to make clear when you use <seg>.

>
> Maybe @flipping/able="no" should be added to the example encoding of the
> Whitman draft?

Yes, done.

>
>> The encoder may choose to combine graphics with the transcription at
>> whatever level is considered effective, or not at all.
>
> The word "combine" seems not quite right, since the graphics themselves
> aren't combined with the transcription but referred to, right?

Revised to

  "The encoder may choose to complement a transcription with graphic 
representations of its source at whatever level is considered effective, 
or not at all."

>
>> Equally, the encoder may choose to provide only graphics without
>> transcription, or with a structured (non-embedded) transcription, or any
>> combination of the three.
>
> As this section is headed "Embedded transcriptions," this strikes me as an
> odd place for this information. Maybe the solution is just to point
> explicitly to the sections where these other approaches are outlined. Also,
> "any combination of the three" might be made more specific; this is
> basically getting at the idea that a TEI document might be made up of any
> combination of<text>,<facsimile>, and<sourceDoc [or whatever]>, right?

Not quite. I am thinking that you might have two types of transcription: 
a "textual" one (trans-t) and a "document" one (trans-d). And you might 
have a version of a document which was just page images. (trans-g)

The following TEI elements exist:

<text> can contain only a trans-t
<facsimile> can contain only a trans-g
<elephant> can contain a trans-d, a trans-g, or both of them

>
>> when dealing with authorial manuscripts,
>
> Is this supposed to mean (and should it therefore read) "literary
> manuscripts"?

No, it is supposed to mean "authorial" in the sense that the person who 
wrote the manuscript is responsible for its intellectual content in a 
different way from say a scribe copying a manuscript which someone else 
has "authored". Would you prefer the word "holograph"? I think 
"literary" would be definitely wrong -- has also sorts of evaluative 
freight!

>
>> To encode such transcriptions, we propose a simple model in which writing
>> traces are marked within a transcription, using an appropriate tag such
>> as mod, del, etc. to indicate their function in the document, as
>> described in the remainder of this chapter.
>
> The voice/tone here seems out of step with the rest of the Guidelines,
> which don't typically "propose" things (IIRC) and don't use the 1st person
> plural. Also, I supressed a smile at "simple model." What about something
> like "The remainedr of this chapter describes a model for encoding such
> transcriptions using tags that mark the functions of various writing traces
> within the document.
>


Have reworded

"The remainder of this chapter describes a model for encoding such
transcriptions, in which elements such as <gi>mod</gi>, <gi>del</gi>,
etc are used to mark writing traces and their functions within the
document."

Let's take the discussion of "layer" v. "changeSet" elsewhere.