Hi Raff Thanks for your questions about datatype. Reviewing the discussion on the pure ODD list (starting in April 2015) is probably the best way of grappling with your difficult "why" questions, so I'm going to mostly just tell you how I think you should be using pure ODD to do what you are currently doing. Firstly, you can use the @restriction attribute to supply a regexp which limits the range of legal values beyond what the indicated datatype would otherwise permit. This deals with your first example (@tab.strings) which should become simply <datatype> <dataRef key=teidata.word restriction="[a-g][0-9](s|f|ss|x|ff|xs|sx|ts|tf|n|nf|ns|su|sd|fu|fd|nu|nd|1qf|3qf|1qs|3qs)?([a-g][0-9](s|f|ss|x|ff|xs|sx|ts|tf|n|nf|ns|su|sd|fu|fd|nu|nd|1qf|3qf|1qs|3qs)?)*"/> </datatype> (though myself I think I'd rather supply a valList) Secondly, whenever the datatype required is "complex" (i.e. permits an alternation or sequence of different datatypes) you *must* predefine the combination required using a <dataSpec>. This is because <dataRef> is always intended to deliver an atomic, primitive, single value. If you want to allow for multiple instances of the same datatype, you can use the occurrence indicators on the parent <datatype>, of course (and that is also why we retain <datatype> as a wrapper, rather than allowing the occurrence attributes directly on <dataRef> itself, and allowing <dataRef> as an alternative to -- rather than child of -- <datatype> which is what was at one stage proposed) So your second and third examples both require an additional <dataSpec> to be defined, the <content> of which will have an <alternate> (or something) wrapping the <dataRef>s you want. For the second case, something like this should work <dataSpec ident="meidata.twoDecimals"> <content> <sequence> <dataRef name="decimal"/> <dataRef name="decimal"/> </sequence> <dataSpec> and then in the attribute <datatype maxOccurs="unlimited"> <dataRef key="meidata.twoDecimals"/> </datatype> And similarly for the third case <dataSpec ident="meidata.weird"> <content> <alternate> <dataRef name="decimal" restriction="[1-9]\.[\d+]" /> <!-- vel sim --> <dataRef name="time"/> </alternate> </dataSpec> Why do we not permit <content> inside <dataType> ? Because that would allow all sorts of nonsense e.g. <elementRef> as well. I cannot now remember why we allow <textNode> but I would certainly not recommend it. Your question also prompted me to review the current dataSpecs for <dataRef> and friends, and thus notice that these don't seem to have any pure ODD examples, which therefore needs to be rectified. On 13/05/16 23:54, Raffaele Viglianti wrote:
<attDef ident="tab.strings" usage="opt"> <desc>Provides a *written* pitch and octave for each open string or course of strings.</desc> <datatype> <rng:list> <rng:oneOrMore> <rng:data type="token"> <rng:param name="pattern"
[a-g][0-9](s|f|ss|x|ff|xs|sx|ts|tf|n|nf|ns|su|sd|fu|fd|nu|nd|1qf|3qf|1qs|3qs)?([a-g][0-9](s|f|ss|x|ff|xs|sx|ts|tf|n|nf|ns|su|sd|fu|fd|nu|nd|1qf|3qf|1qs|3qs)?)*</rng:param> </rng:data> </rng:oneOrMore> </rng:list> </datatype> </attDef>
Solution: bite the bullet and move it to a dedicated <dataSpec>
2. The datatype combines a number of pre-defined datatypes Example: <datatype> <rng:list> <rng:oneOrMore> <rng:data type="decimal"/> <rng:data type="decimal"/> </rng:oneOrMore> </rng:list> </datatype>
Solution: again create a dedicated <dataSpec>, but it's a bit annoying since this it's just a matter of combining already defined datatypes in a specific way.
3. The datatype involved a choice between a number of pre-defined datatypes Example: <datatype> <rng:choice> <rng:data type="decimal"> <rng:param name="minInclusive">1</rng:param> </rng:data> <rng:data type="time"/> </rng:choice> </datatype>
Solution: like 2., but there is also another question: we're relying on the rng datatype for time. Will we have to define our own? Can we use rng's or xsd's definition without breaking the Durand Conondrum?
General question: What's the reason to not allow <content> in <datatype>? It also seems a bit strange to allow either dataRef or textNode - it seems to me that it's mixing a reference and a definition, but only if it's a text node. It would seem more logical to just replace <datatype> with <dataRef> and use it to refer to a text datatype. Or, better, just allow datatype to define the datatype there and then like it used to :)
Thanks, Raff