re 4. : in this case we could leave <app> as <appSpan>, since it's what it actually does, and this way the addition of "higher-level" sorts of <app>s would not bite you if you have been using <app> before.
----- Mail original -----
De: "Stuart A. Yeates" <[log in to unmask]>
À: [log in to unmask]
Envoyé: Mercredi 20 Mai 2015 00:21:51
Objet: Re: Encoding divergent ending of a story (or: the <app> strikes back)
4. split <app> into three. <appSpan> which can appear anywhere a
<span> can and contains one or more <span>-level alternatives, plus
metadata. <appP> which can appear anywhere a <p> can and contains one
or more <p>-level alternatives, plus metadata, <appDiv> which can
appear anywhere a <div> can and contains one or more <div>-level
alternatives, plus metadata,
This preserves the integrity of the content model, right?
Following this to it's logical conclusion we may also want a spanC,
but that may be overkill.
...let us be heard from red core to black sky
On Wed, May 20, 2015 at 10:12 AM, Sebastian Rahtz
<[log in to unmask]> wrote:
>> On 19 May 2015, at 22:53, 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).
> Allowing <app> to both be a child of <p>, to to contain <p>, and to be a sibling of <p>, would be an interesting challenge for
> the TEI content model writer. Not that this should put you off, I hasten to add. It may be no harder than making <app> behave like
> <q>. When I (as a processor of TEI texts) tell you that <q> gives me more headaches than other element, that shouldn’t worry you, either.
> You plainly describe a real situation. So the TEI has 3 choices:
> 1. tell you to use standoff except when an app is inline (the status quo)
> 2. compromise on a <q>-like <app> which may do an 80/20 job for you (but wouldn’t work with existing tools)
> 3. create a new <appBlock> which can appear anywhere, and behaves like Magic
> Luckily, I don’t have a vote, so I don’t have to tell you which I prefer.
> Sebastian Rahtz
> Chief Data Architect, IT Services