<div dir="ltr"><div><div><div>All,<br></div><br></div>I am attempting to spawn this thread out of the &#39;vo-dml for cube&#39; subject which has expanded into multiple inter-related topics.<br>  <a href="http://mail.ivoa.net/pipermail/dm/2015-December/005271.html">http://mail.ivoa.net/pipermail/dm/2015-December/005271.html</a><br><br></div><div>The request is that the vo-dml specification be modified to allow a variable multiplicity in Attributes.<br></div><div>The current document (Oct 2015) states in Section 4.14: Attribute<br></div><div>  &quot;The multiplicity of Attributes is restricted to be either 0..1, or n..n where n is a positive integer literal.  i.e. open ended collections are not allowed, nor is 0..n, with n&gt;1.&quot;<br><br></div><div>  and in Section 4.19: Multiplicity<br></div><div>    &quot;A special case is the assignment of a Multiplicity to an Attribute.  The only combinations of minOccurs..maxOccurs that are allowed on attribute definitions are 0..1, 1..1 (or simply 1), and n..n (or simply n) with n&gt;1.  i.e. for multiplicity greater than 1 the attribute can be interpreted as an array of fixed size.&quot;<br><br></div><div>Gerard explains the reasoning as:<br>  &quot;Motivation for disallowing * is somewhat philosophical, related to the semantics of datatype. Also related to the type of data models VO-DML is targeting. VO-DML is aimed at models that can give a conceptualization of a domain, rather than providing an implementation/serialization. For the latter we have our VOTable mapping document for example, where the vo-dml is used in annotations.<br>Idea is that if you have a collection-like concept for which you do not know how many instances you will have (i.e. multiplicity is *), it becomes a meaningful action to first state that such an instance exists and then that it is contained in the collection on a certain object. Such a concept should be modelled by collection of object types, not list of data types.&quot;<br><br></div><div>There are, however, several instances in the current model work where this approach has not been followed.<br></div><div>  STC2:<br></div><div>    - array of coefficients in a Polynomial transform definition<br></div><div>    - number of coordinate values along an enumerated coordinate axis (Enum transform)<br><br></div><div>  Dataset:<br></div><div>    - Curation.reference = string[0..*]<br>    - DataID.collection= string[0..*]<br>    - DataID.contributor= string[0..*]<br></div><div>    NOTE: the STC2 prototype also contains the above transform related items<br><br></div><div>  Cube:<br></div><div>    - PointData.customAxes = GenericCoord[0..*]<br></div><div>        a list of coordinate values not representable by the domain-specific coordinate types.<br></div><div>        GenericCoord is a dataType, so customAxes is an Attribute, and this multiplicity is not allowed.<br></div><div><br></div><div>  VO-DML<br></div><div>    - Model.author = string[0..*]<br><br></div><div>Plus some speculated cases which have not been modeled.<br></div><div>  - pixel data values in a spectrum<br></div>  - number of samples in a time series.<br><div><div>  basically dimensionality of values;  ndim[1],  values[ndim]<br></div><br><br></div><div>Gerard has suggested:<br>  &quot;I think we should allow 0..n for attributes, but with a different interpretation from its counterpart in composition relations and references.  It would imply that the value of the attribute is either 0, or an array of length exactly n.  In relations the interpretation remains that one can have between 0 and n (inclusive) instances in the collection.&quot;<br><br>and added:<br>  &quot;Allowing n to be an integer attribute with multiplicity 1 I am still strongly against.  For example, what if, after initializing the 0..n attribute, you change the value of n?&quot;<br><br></div><div>(Which is an excellent point. BTW)<br></div><div>However, this suggestion does not, I think, resolve any of the above cases since the number of instances is not known.<br><br></div><div>For the simple string cases, creating an object to hold the string datatype would resolve the compliance issue, but seems overly complicated.   Once could argue that you wouldn&#39;t, necessarily, need to serialize the containers, but I would not like to see different serialization rules for simple containers vs complex ones.<br><br></div><div>The more complex cases, one could/should question the modeling to be sure the approach is correct (on appropriate separate thread).  Which may or may not find an alternate solution.<br><br></div><div>For those requesting n = non-negative integer attribute with multiplicity 1:<br><div>  perhaps in these cases, n is not a modeled property, but derived from the length of the array.  if so, <br></div>  then these become open-ended values[*] which matches the above cases. constraints can restrict &#39;* = 1,2,3&#39;<br><br></div><div>So the issue is still un-resolved, and in my opinion, the string cases may be the better to focus on since they would generate the most overhead for the least benefit.  We would have several objects, which simply hold the primitive value<br></div><div>  Author.name:string[1]<br></div><div>  Reference.refString:string[1]<br></div><div>  Collection.tag:string[1]<br></div><div>  Contributor.entity:string[1]<br><br></div><div>or maybe just<br><div>  Author.value:string[1]<br></div><div>  Reference.value:string[1]<br></div><div>  Collection.value:string[1]<br></div>  Contributor.value:string[1]<br><br></div><div><br></div><div>I&#39;ll close with an opinion on the suggested change to allow 0..n with special interpretation.<br></div><div>I expect there may be use cases where there will be a need for optional fixed array attributes<br></div><div>(served by 0 OR n with literal n), but I don&#39;t think we&#39;ve seen them yet.  I think that using the <br></div><div>notation 0..n will be widely misinterpreted when people are reading the model diagrams.<br></div><div>The notation &#39;0,n&#39; would be more intuitive, but not standard.  So, this feels like a combination <br></div><div>of multiplicity and constraint:   multiplicity = &#39;*&#39; with constraint &quot;* = 0,n&quot;<br><br></div><div>Mark<br><br></div><div><br><br></div></div>