My off-the-top-of-my head vote is for the more restrictive interface, however I think it quite reasonable to have a <sequence> in a <dataSpec> definition. (Whereas <empty>, <anyElement>, <elementRef>, <classRef>, and probably even <macroRef> do not make sense.) That said, one of the reasons I prefer the more restrictive interface is that it helps make easy things easy. A user can always still edit an ODD by hand. Why <sequence>? I dunno. Imagine <dataSpec ident="data.bloodPressure"> <content> <sequence> <dataRef n="systolic" name="nonNegativeInteger" restriction="[123]?[0-9][0-9]?"/> <dataRef n="diastolic" name="nonNegativeInteger" restriction="1?[0-9][0-9]?"/> </sequence> </content> </dataSpec>
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