[tei-council] Location of <app>s for external apparatus

Sat Jun 16 02:02:16 EDT 2012

On 12-06-15 03:21 PM, Kevin Hawkins wrote:

>>>
>>> one could almost posit _another_ sibling of<text>    called<standoffText>    where
>>> all this stuff lives.
>>
>> I think one should seriously posit such a thing. A born-digital document
>> is a very different scenario from a traditional
>> transcription-from-source, and leaving born-digitals aside for the
>> moment, we have a situation where the original source document probably
>> has<front>,<body>   and<back>, and all the real original content would
>> be transcribed there, in the order in which it appears. Adding in
>> standoff content to<back>   is ambiguous, and problematic for anyone
>> writing stylesheets or other processors. And I share James's unhappiness
>> with suggesting that something as ill-constrained as @type be used to
>> distinguish the two cases.
>>
>> So I like the idea of a fourth child of<text>, which explicitly
>> contains stuff which is out-of-sequence, editorial, or otherwise not
>> part of the normal flow of the source document. I don't like the name
>> <standoffText>, though, because it may not always be textual stuff;
>> <linkGrp>s and<link>s belong there too, for instance.
>
> And<interpGrp>!  It has long driven me crazy that you insert this in
> <back>  even though it basically never occurs in the source document but
> that there isn't a recommended way to indicate that such an element is
> not meant to be rendered as part of the encoded text.

Good point! Are there any others I've forgotten?

> So I would be very interested in the fourth child of<text>  as well.
> But I wonder whether we can solve the<listApp>  problem separately, even
> only for those who are encoding an apparatus that occurs in the source
> document.

I think we definitely do need <listApp> anyway, and people will find it 
useful without this extra text child, but we're not going to have it 
ready for Monday's release, so we might as well think about the whole 
package together. It would be nice to be able to rewrite the Guidelines 
not only to introduce <listApp> but also to recommend a place to put it, 
along with other similar stuff.

>> We need a name that incorporates the idea that these items are not part
>> of the source document flow, although they may include text which ends
>> up being rendered into that flow.
>
> <supplements>?

Yes, or <supplementary>, or <extras>? None of these is quite right 
somehow...

Cheers,
Martin

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre