Hello Council and Lou, As I'm working on supporting dataSpec in RomaJS, I've been thinking about what an interface for defining a datatype's content would look like. I did a quick survey of teidata.* source files and it looks like <content> is limited to this pseudocode content model (I hope it makes sense): (dataRef* | valList | textNode) | alternate { (dataRef* | valList | textNode) } I don't see any use of <sequence>, <empty>, <anyElement>, other *Ref elements besides dataRef, or multiple <valList>s and <textNode>s. This makes perfect sense to me. The question is: should I limit the interface to allow users to build only datatypes that "make sense", or allow more flexibility? The advantage of a more restrictive approach, which I support, is that the interface can be more to the point. If we wanted more flexibility, I'd implement the Blockly interface that is currently in use for <elementSpec>s. But I think it might discourage people from defining good datatypes as it's not immediately obvious how to use it. I wanted to run this by the group to make sure I analyzed this correctly. Does this make sense? Also a quick reminder to fill the Doodle for a call in the second week of February if you're interested in participating https://doodle.com/poll/8p7exq3vptpb8g9t Thank you! Raff