Pat,
> Also, no one seems to have noticed that CoreQ allows for either arrays or
> components (parent-child structure) BUT NOT BOTH at the same time!!!
Not sure what you mean by "CoreQ allows for either arrays or components". I understand "CoreQ allows for arrays" in that the "valuesList" may be multi-dimensional, but I do not understand "CoreQ allows for components". Is this to do with the issue of whether a CoreQuantity in which the Frame represents a 2-d phenomenon such as "sky position" should be seen as composed of a pair of 1-d "component" Quantities? If so, then the documented interface does *not* include such a concept, even though the suggested serialisation may. I think this difference in the interface model and the serialisation model is possibly one of the main problems with the current document. Note, the getParent() method is nothing to do with components in this sense - it is to do with chaining, not enclosure. It returns the CoreQ which "feeds" input values to the Mapping.
> I also argued unsuccessfully that these two kinds of things should be
> separate, which I why (way back last fall after adass) I proposed
> AtomicQuantity, ArrayQuantity, and CompositeQuantity as 3 sibling types
> (the domain model didn't have ArrayQuantity). But that eventually got shot
> down in favour of cramming several distinct concepts together....
No comment - I wan't included in that debate!
David
STARLINK project | Centre for Astrophysics (http://www.starlink.ac.uk/) | University of Central Lancashire Rutherford Appleton Laboratory | PRESTON DIDCOT | United Kingdom United Kingdom | PR1 2HE OX11 0QX Tel. 01772 893733 01257 273192Received on 2004-05-11Z17:00:17