I think Marjorie request is quite reasonable. Stand-off is fascinating, but when you come to applying it to real cases it is also painful, hard to apply and control, and you end up to hide a lot of the representation in the "would be" processing tool (otherwise we would had abandoned XML in the end... to recall a recent thread).

I agree that IFF you can do the easy way (inline markup) then do it. Of course I am not taking into account the tech problems to implement it in a content model, but I find really wrong to give up reasonable changes in the schema if a way to express it in XML is available (although difficult).

On the other hand I really do no like extending the set of tags when there is no real need (Ockam principle): the <app> element stand for apparatus, and apparatus does not change its very nature if it represents variation at phrase or block or even container level. So I think that Marjorie should raise asking the more natural and obvious modification, then the tech council will discuss and eventually find a technical way to do it. I would add that this request strengthen the awareness that the whole apparatus module should go under a deep revision.

f

2015-05-20 9:39 GMT+02:00 Jens Østergaard Petersen <[log in to unmask]>:
I am all for standoff markup, but I think one argument for parallel segmentation is that it is humanely comprehensible. Having alternatives to choose from represented as children of the <app> element is simply easy to grok. This must be in the background of this debate, but it is seldom expressed, perhaps because standoff markup is technically more advanced – and no one wants to be seen as being challenged in that respect. 

However, we can only juggle around with so many anchors and xml:ids in our heads at one time, so there needs to be a way to convert between inline markup and standoff markup. I have experimented with this, round tripping inline TEI (with text-critical markup) to standoff markup, and it can be made to work (skewed overlaps result in multiple representations of the text with overlaps). 

The use case Marjorie has for a block level <app>, where a number of block level elements alternate on their presence, is the simplest one. The real challenge is to encode a number of block level elements with different order – and not duplicating a lot of contents in the process. There is also a standoff solution for this, involving flattening the XML hierarchy, reordering it and then combining it again – a real Humpty-Dumpty if you will. 

I have not had time to play with this for quite a while. Some of the code is in <https://github.com/jensopetersen/ShakespeareStandoff>, some in <https://github.com/jensopetersen/mopane>, and some in my head – needless to say, this work is far from completed. Ah, yes: I should admit that the standoff markup I use is not TEI-based …. See also <https://stackoverflow.com/questions/21527660/transforming-sequence-of-elements-to-tree> and <https://stackoverflow.com/questions/20729593/transforming-tree-to-sequence-of-elements> for the help I got in coding the block level problem.

Jens

On 19 May 2015 at 23:54:19, Burghart Marjorie ([log in to unmask]) wrote:

Sebastian, what you describe is actually what happens in real life. Of course, a whole chapter, present in some manuscripts, can be omitted in others, so <app> should indeed be allowed to contain <div>s.
Just making <app> to be a sibling of <p> would already be an improvement. But what would be really useful would be to allow <app> to contain several <p>s, just like a <div>. I'm guessing that containing <div>s is not the most important thing, if it helps with the content model (and your quills). In the case of the present / omitted chapter mentioned above, for instance, instead of this:

<app>
<lem>
<div type="chapter">
<p>...</p>
<p>...</p>
<p>...</p>
<p>...</p>
</div>
</lem>
<rdg wit="#C #D"/>
</app>

we could have a structure like this one:

<div type="chapter">
<app>
<lem>
<p>...</p>
<p>...</p>
<p>...</p>
<p>...</p>
</lem>
<rdg/>
</app>
</div>

That would be satisfying enough.


----- Mail original -----
De: "Sebastian Rahtz" <[log in to unmask]>
À: "Burghart Marjorie" <[log in to unmask]>
Cc: [log in to unmask]
Envoyé: Mardi 19 Mai 2015 23:23:35
Objet: Re: Encoding divergent ending of a story (or: the <app> strikes back)


> 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



--
Fabio Ciotti
Dipartimento Studi Umanistici, Università di Roma Tor Vergata
Presidente Associazione Informatica Umanistica Cultura Digitale