[tei-council] Fwd: TITE again

[Rebecca Welzenbach]

As I recall, one of the concerns about bringing these elements into P5 is
that it provides even more ways of doing things--it makes the landscape
more complicated, rather than less complicated.

As Martin Holmes said:

> <b>stuff</b>
>
> is simpler, clearer and more user-friendly than either of these:
>
> <hi rend="bold">stuff</hi>
> <hi rend="font-weight: bold;">stuff</hi>
> <hi style="font-weight: bold;">stuff</hi>

In and of itself <b>stuff</b> is simpler, but bringing it into P5
complicates things by offering yet another apparently equivalent choice,
right?

Rather than incorporating these convenience elements into P5, what if we
instead explicitly acknowledge that people might use any number of
shortcuts for efficiency in their own projects, and offer some basic
support for transforming such texts to P5? I don't know if this would fit
best in the Guidelines or somewhere else like the wiki (I guess it depends
on how formally we want to support it), but I can imagine a document saying
something like:

"Many people find it convenient/effective to help vendors/students/the
crowd, who have limited experience with TEI and/or with the textual
material at hand, encode consistently by using "shortcut elements" for
common, easily recognizable features. When encoding is complete, the texts
are processed, and these shortcut elements are expanded into valid TEI P5
elements.

For example: *stuff * might be transitionally captured as <b>stuff</b>, and
then transformed in processing to <hi rend="bold">stuff</hi>

TEI Tite (
http://www.tei-c.org/release/doc/tei-p5-exemplars/html/tei_tite.doc.html)
is an example of an entire schema designed around supporting this kind of
off-site text encoding. TEI Tite uses the following shortcut elements:
b<http://www.tei-c.org/release/doc/tei-p5-exemplars/html/tei_tite.doc.html#b>
, i<http://www.tei-c.org/release/doc/tei-p5-exemplars/html/tei_tite.doc.html#i>
, ul<http://www.tei-c.org/release/doc/tei-p5-exemplars/html/tei_tite.doc.html#ul>
, sup<http://www.tei-c.org/release/doc/tei-p5-exemplars/html/tei_tite.doc.html#sup>
, sub<http://www.tei-c.org/release/doc/tei-p5-exemplars/html/tei_tite.doc.html#sub>
, smcap<http://www.tei-c.org/release/doc/tei-p5-exemplars/html/tei_tite.doc.html#smcap>
,cols<http://www.tei-c.org/release/doc/tei-p5-exemplars/html/tei_tite.doc.html#cols>
 and ornament<http://www.tei-c.org/release/doc/tei-p5-exemplars/html/tei_tite.doc.html#ornament>

Regardless of the schema you use for your project, if you use this list of
shortcut elements in your project, you can use [this transformation/this
set of regular expressions] to expand your shortcut elements to P5. Of
course, you may also invent any shortcuts that are useful for the purposes
of your project, and design your own post-processing workflow to transform
the transitional encoding to conform to the archival schema you have
selected for your project."

I like this for a few reasons:

   - it offers support for a customizable approach to encoding projects,
   rather than rubber-stamping some shortcuts as valid and others as not
   (regardless of how much more frequently <sup> is used than <sub>, it just
   seems unbalanced, in many ways, to allow one and not the other).
   - It also lets encoders go either way: fallback on convenience and rely
   on some default expansion of the shortcut element (which I guess we would
   define for them), or choose for themselves how they really want the bold
   text to be encoded.

However, this suggestion does not really get at the problem of making
things more interoperable, because in the final TEI document, text that was
bold in the original might still be encoded in several different ways.

Becky

On Sun, Jul 15, 2012 at 12:53 PM, Sebastian Rahtz <
sebastian.rahtz at oucs.ox.ac.uk> wrote:
>
> On 15 Jul 2012, at 17:29, Martin Holmes wrote:
>
>> This makes me rather uncomfortable, because we're unambiguously
>> importing presentational elements into the schema.
>
> sure. but this is just somewhere a bit further along the
> scale on which lists, tables, page breaks,  etc sit, I would
> argue. I don't think there can be a black and white case against <b>,
> <i>, <sup> and <sub>.
>
>>
>> There is one other option, though: the kiss module could explicitly
>> import elements from the XHTML namespace.
>>
> that surely defeats the point, if you have to say <xhtml:b> and declare
> the prefix? One could certainly use <equiv> to note the relationship,
> I think.
>
> a module called "typesetting" or "presentation" (not "kiss" :-})
> would do the job, and would even allow for a <font> element
> (no, I am not joking).
>
> There is a question, perhaps, over whether we should start
> talking about a TEI profile called "core", which we promote
> instead of "tei_all" as the normal test of TEI goodness. and that
> would not include the "typesetting" module. Cue lengthy argument.
>
> All that said, I don't think this request is so urgent that we shouldn't
> just put it on the agenda for the autumn. I'd much rather
> we resolved some requests which more genuinely block TCP translation,
> eg  3531957, 3531963, 3439980 - especially the latter!
> --
> Sebastian Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
>
>
>
>
>
> --
> 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