[vodml] Attribute multiplicity
CresitelloDittmar, Mark
mdittmar at cfa.harvard.edu
Wed Dec 30 18:54:17 CET 2015
Gerard,
Wow.. pictures and everything!
A couple quick comments.
1) various [string 0..*] attributes
I agree that all of the examples I gave represent concepts which
**could** be expanded with other attributes.
In that regard, modeling them as such would be more 'correct'.
However, we have NO use cases which
require any more than the simple string representation. So the
question becomes "is it cost effective to do so?".
I included the vodml Model.author example half expecting that the
document was not required to follow the
specification itself, but it illustrates the point. You responded "not
doing justice to the Author concept, but makes it easier to write and
parse/interpret a model document."
And this is the point. I/we understand that we are not doing justice
to the "Contributor" concept (for example), but
the simple string array attribute is easier to interpret and serves the
requirements.
2) Polynomial
My initial reaction is "what you describe is an entirely different
goal".
The STC Transform model is not trying to model the mathematical
operations/functions. It is encapsulating
the user-provided specifications required by those operations. The
Axis, for example, is not part of the
transform spec, because the operation is applied to a coordinate which
has the Axis association. The
same mathematical operation could be applied to different axes
3) parameterized array [ n=nonnegativeInteger[1]; values:real[0..n] ]
Laurent argued that a Constraint definition would be able to deal with
this. I agree with that.
I think I've missed this point. Also, if the interpretation is 0 OR
n, and n must be an expressed literal (e.g. 0..4), then I do not see how
constraints help here.
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20151230/94b32dc8/attachment.html>
More information about the dm
mailing list