[tei-council] allowText

[Lou Burnard]

On 09/06/14 12:43, Sebastian Rahtz wrote:
> On 9 Jun 2014, at 12:21, Lou Burnard <lou.burnard at retired.ox.ac.uk> wrote:
>
>> Sorry to bang on about this, but we need to resolve the issue.
>>
>> I want to express in pure ODD the content model (text | a | b)*
>>
>> I can imagine 3 ways this might be done in pure ODD
>>
>> (a) <content allowText="true">
>>         <elementRef key="a"/>
>>          <elementRef key="b"/>
>>      </content>
>>
>> (b) <content  allowText="true">
>>         <alternate>
>>           <elementRef key="a"/>
>>           <elementRef key="b"/>
>>         </alternate>
>> </content>
>>
>> (c) <content >
>>         <alternate allowText="true">
>>           <elementRef key="a"/>
>>           <elementRef key="b"/>
>>         </alternate>
>> </content>
> i would go with the most explicit (c) every time, as most extensible/sustainable.
> i don’t read a) as meaning "(text | a | b)*”

That's because you don't consider the full implications of @allowText.
>
>> Of these only the first currently generates (text | a | b)*  The second
>> generates
>> (text | (text | bit | bob))* which is gibberish; the third generates
>> just (a | b)
>>
> behaviour of c) is a bug. a) is tricky - the current output is not ideal,
> but is an LCD

Eh? What does the display device have to do with it?

However, if we agree that (c) and (b) are bugs, we are definitely making 
progress.


>
>
>> Personally, I stand by my view that (a) is the right way to express the
>> required content model. It is not ambiguous unless you think that
>> multiple ungrouped elementRefs implies a sequence. But if that were
>> true, why did we invent the sequence container?
> to group them together in alternates?

you mean to alternate sequences? yes, but do we really want two 
different ways of indicating a non-alternated sequences ?

<content>
   <elementRef key="a"/>
   <elementRef key="b"/>
</content>

and

<content>
<sequence>
   <elementRef key="a"/>
   <elementRef key="b"/>
</sequence>
</content>

both generate the same rng, though as previously noted there is a bug 
causing the former to generate invalid DTD

>
>> p.s. I haven't included occurrence indicators above; if you do they are
>> always ignored anyway. In the fullness of time they should generate an
>> additional schematron constraint perhaps.
> some of them work…

small earthquake. not many dead.