[tei-council] valList, content etc

[Sebastian Rahtz]

Syd commented to me on this issue to me. See below. I think he is  
right in many ways, but my gut reaction is that this is for ODD 3 not  
our current ODD 2

>
> That said, my instinct is that it's a reasonable idea. In some sense,
> what we really want is
>
>  macro.contentModel = (
>      element constraintSpec {
>         attribute scheme { "relaxng" },
>         (  rng:ref | rng:group | rng:zeroOrMore |
>            rng:choice | rng:empty | rng:oneOrMore |
>            rng:text | rng:data | rng:optional )
>         }
>      |
>      element constraintSpec {
>         attribute scheme { "tei" },
>         valList
>         }
>    ),
>    element constraintSpec {
>       attribute scheme { "schematron1.x" },
>       ( sch:ns | sch:phase | sch:pattern |
>         sch:rule | sch:report | sch:assert )
>       }*
>    element constraintSpec {
>       attribute scheme { "isoschematron" },
>       ( isch:ns | isch:phase | isch:pattern |
>         isch:rule | isch:report | isch:assert )
>       }*
>
> Although we can't use RELAX NG like that, of coures, and I forgot the
> <constraint> level. (It's the idea that counts. :-) We could use
> Schematron to enforce some or all of this stuff, though. The
> flexibility here would permit the list of elements allowed in
> <constraintSpec scheme="tei"> to expand over time, if that's a
> direction Council wanted to go in.
>
> (BTW, the lists of allowed child elements may well be off by a few
> here or there -- I didn't do a lot of thinking there. The point is
> that having a list of elements allowed is more helpful than
> macro.anyXML. E.g., you don't want to have <sch:schema> or
> <rng:start> in there.)

--
Sebastian Rahtz
Information Manager, Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

Sólo le pido a Dios
que el futuro no me sea indiferente