[Trying to channel Raff, who is probably still asleep.]

1. Actual content model (that Raff was discussing -- i.e., a model
against which all of our current dataSpec/content elements are
valid):

   ( dataRef* | valList | textNode | aDr | avL | atN )
   aDr = element alternate { dataRef* }
   avL = element alternate { valList }
   atN = element alternate { textNode }


2. No, Raff was not suggesting any change to content models, only to
his user interface in RomaJS.

But now that you point it out, it would probably make sense to
disallow at least <empty>, <anyElement>, <elementRef>, & <classRef>,
and probably even <macroRef> from the <content> of a <dataSpec>.

> Firstly, I dont understand your pseudocode content model.  Does it
> mean the same as the following:
>
> <alternate minOccurs="1" maxOccurs="undefined">
>    <elementRef key="dataRef"/>
>    <elementRef key="valList"/>
>    <elementRef key="textNode"/>
> </alternate>
>
>
> Are you proposing to change the current content model of <content>
> or of <dataSpec> ?
>
> In either case, I suggest defining a class model.dataSpecPart might
> help.
>
> Or is it just about how selective your interface should be in what
> it permits, perhaps as a not-so-subtle way of avoiding the
> question?
>
> Current practice in defining dataSpecs is constrained by what was
> done in P4: I re-used the <content> element here because we also
> used it to define the expansion of macroSpecs (i.e parameter
> entities) back in the day, but that's a historical explanation.
> This over-generates, as you rightly say: it's not at all clear what
> it might mean to put e.g. an elementRef into the content of a
> dataSpec!
_______________________________________________
Tei-council mailing list
Tei-council@lists.tei-c.org
http://lists.lists.tei-c.org/mailman/listinfo/tei-council