- Sebastian, I agree that every element can be involved in variation and.... I can only vaguely imagine the tremendous problems for TEI content models, so a compromise would probably be the best!

- Limiting to a problem that, I guess, often happens, when the textual variation is at block-level, it should be encoded with block-level <app>!
Seems more straightforward than all possible alternatives ...

- "normal" TEI user would worry about processing when encoding. 
Which tools are available and which techniques you can use may in practice influence your way of encoding ... e.g., xpointer is a powerful standard, but pretty nothing can handle it.

(Big voices are speaking there, forget me if I am saying nonsense :)

Best wishes,
Elena S

Elena Spadini

Huygens ING - DiXiT Marie Curie fellow
PhD candidate Sapienza Università di Roma

2015-05-19 22:23 GMT+01:00 Sebastian Rahtz <[log in to unmask]>:

> On 19 May 2015, at 22:06, Burghart Marjorie <[log in to unmask]> wrote:
> I would argue that the point is not to loosen the TEI model, but to correct it.
> As it is, the TEI model is assuming that variants do not occur at div or paragraph levels. This is just plain wrong.

Hang on, now. You started asking for <app> to be a child of <div>, to allow for an entire paragraph
being a variant. Now you’re saying that an entire <div> can be a variant; and I would assume you also
would say that a <front> or a <titlePage> can be a variant too?

Nothing wrong with this, but it raises horrendous problems in actually constructing TEI
content models which support what you describe. My hair is doing its "quills upon the fretful porpentine”
thing at the thought. You’d have to make <app> a member of model.global, so it could appear
_anywhere_, and then give it a content model not unlike <floatingText>. And then you’d have
to learn how to process it.

If you want to compromise by saying that you just want <app> to be blocklike, i.e. be a sibling of <p>,
my quills relax.

Sebastian Rahtz
Chief Data Architect, IT Services