[tei-council] allowText

[Sebastian Rahtz]

On 9 Jun 2014, at 13:17, Lou Burnard <lou.burnard at retired.ox.ac.uk> wrote:

>> 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.

I’d claim back that you’re limiting yourself to XML rules, which we don’t need to.

>> 
>>> 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?

lowest common denominator

> ...
> 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


I can live with that. the <sequence> is just putting in extra (), as one often
does unnecessarily.

why people think occurrence constraints are ignored baffles me, there is plenty
of code supporting them….
--
Sebastian Rahtz      
Director (Research) of Academic IT
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

Não sou nada.
Nunca serei nada.
Não posso querer ser nada.
À parte isso, tenho em mim todos os sonhos do mundo.