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:
<rdg wit="#C #D"/>
we could have a structure like this one:
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.
Chief Data Architect, IT Services