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