[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!