This comes back to a central concern I have with both block-level
app solutions and standoff app solutions using listApp. In all
cases what is missing is friendly human-readable tools. It is
perfectly easy (for an XSLT-savvy person) to write one hierarchy
of <app> elements into a file, and then generate standoff version
stored in <listApp>, and similarly, the reverse, take that list
of standoff <app> entries and put them back into the main text. I
Iike the ShakespeareStandoff example below. The problem is that
there is no defacto general and commonly accepted tool for doing
so. Standoff markup is great and (at @xml:id identified
word-based granularity) my intellectually-preferred method for
doing things. I wish there was a tool which your beginning TEI
user could easily use to create standoff annotation (of <app> or
any other nature) in a simple and easy to use manner. They
shouldn't be required to hand-code adding particular IDs etc.
Now, in the past I've built tools (bespoke XSLT stylesheets) to
do this kind of thing, but it isn't generalised, user-friendly,
or easy for those who don't want to do the very precise thing I
might have done and whose underlying TEI is not precisely
organised the way mine is. Like you I prefer parallel
segmentation for my apparatus whenever possible, but also would
like to be able to remove that from view (swap it to standoff)
while working on other non-app related markup.
Just thinking out loud,
On 20/05/15 08:39, Jens Østergaard Petersen wrote:
> 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
> for the help I got in coding the block level problem.
> On 19 May 2015 at 23:54:19, Burghart Marjorie
> ([log in to unmask] <mailto:[log in to unmask]>)
>> 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:
>> <div type="chapter">
>> <rdg wit="#C #D"/>
>> we could have a structure like this one:
>> <div type="chapter">
>> 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
Dr James Cummings, [log in to unmask]
Academic IT Services, University of Oxford