List of stuff allowed in <content>, in general: alternate, classRef, [dataRef], elementRef, macroRef, sequence, textNode, valList; and, of course, anyXML (to allow RNG) List of stuff that should be allowed in dataSpec/content (IMHO): alternate, [dataRef], macroRef, sequence, valList And by "in", I don't mean "child of", but "descendant of". Personally, I think that is sufficiently different that (as I said in Ann Arbor) a different element than <content> is called for. But since we're using <content>, the test for icky stuff isn't that hard: <sch:rule context="tei:dataSpec/tei:content//*"> <sch:assert test=" self::tei:alternate | self::tei:dataRef | self::tei:macroRef | self::tei:sequence | ancestor-or-self::tei:valList ">A <sch:name/> should not be used to define the content of a datatype (<sch:value-of select="ancestor::tei:dataSpec/@ident"/>)</sch:assert> </sch:rule> And then we can do a better job of it in the future when PureODD supports co-occurrence constraints.

I'm still poking away at my datatype replacement ticket ...

We agreed that <dataSpec> should be used to fully specify a TEI-defined datatype and also noted in passing that its existing <content> child needed additional constraints (e.g, it shouldnt allow you to supply elementRefs)

In fact it seems to me that the "content" of a dataSpoe should be much more restrictive: I'd like for it to contain just <alternate>, <sequence>, <valList>, or <dataRef>, with the additional constraint that <alternate> and <sequence>s it contains can contain only one or more <dataRef>s

If no-one has any counterproposal that's what i am planning to try to implement anyway.