dataSpec content
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
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
Hi Raff 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! best wishes Lou On 01/02/2019 21:45, Raffaele Viglianti wrote:
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
[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!
participants (3)
-
Lou Burnard -
Raffaele Viglianti -
Syd Bauman