STC2 Model and VO-DML Issues

[Arnold Rots]

We have recently had some discussions on VO-DML in the context
the the STC2 model, that Mark suggested should be summarized to
the DM list to entice larger participation.

The current version of the STC2 model is now posted on:
https://volute.g-vo.org/svn/trunk/projects/dm/vo-dml/models/STC2/2015-10-30/
As reported yesterday, the following action items have been resolved:
- Transformations are done in atomic fashion, following the AST style
- Gerard has a scrippt that will process the XMI file
The following actions are in progress:
- Complete the enumerations of standard frames and standard positions
   This is trivial and quick
- Complete the in-model documentation
   Most description boxes in the documentation are still empty
- Investigate (and experiment with) defining specialized coordinates
   through subsetting. A first attempt is contained in the Specialized
   package; but it is not clear this is worthwhile.
The following items are still to be tackled
- Writing a WD
   It probably makes more sense to draft that on the basis of completed
   documentation (see above)
- Collaborating with whoever (if anyone) is working on the Units model
   The issue is the mechanism to restrict units according to context;
   STC2 includes such a mechanism, but this needs to be done in
   consultation
- Generate a library from the processed model
   The intent is that this be linked to the AST library for transformations
- Resolve remaining VO-DML issues


This last point is the second subject of this message.
There are two places where the STC2 VO-DML model runs into trouble.

One is a relatively trivial one. I would like to request that the VO-DML
WD include a section on the syntax of Constraints. It is hard to find
documentation on this (at least, I find it hard), and adding his would be
very helpful.

The other concerns the multiplicity of datatype attributes.
Attributes can only have a specific length, specified in the model;
i.e., an object cannot contain a variable array of values.
STC2 runs into this in some places where that rule is uncomfortably
restrictive; for example:
—- A polynomial object cannot contain an order and an array of coefficients,
   its length determined by the order
—- One cannot leave the dimensionality of a value (1, 2, or 3) open
—- The coordinate values of an enumerated axis cannot be specified in a
vector
The way to get around this is to turn these items into objects/classes.
But that, in my view, unnecessarily complicates the model further, since
a simple array of data values suffices in these situations.
Dynamic sizing of arrays/vectors of data values at the time of instantiation
is, I think, a must.


This is a summary of the arguments I have made over the past few days;
I'll leave it to the other participants to voice their opinions.

Cheers,

  - Arnold

PS: My access to internet connectivity will be spotty, at best, this coming
week.

-------------------------------------------------------------------------------------------------------------
Arnold H. Rots                                          Chandra X-ray
Science Center
Smithsonian Astrophysical Observatory                   tel:  +1 617 496
7701
60 Garden Street, MS 67                                      fax:  +1 617
495 7356
Cambridge, MA 02138
arots at cfa.harvard.edu
USA
http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20151031/b5af5e8e/attachment.html>