[QUANTITY] and [OBSERVATION] data models: new drafts - comments on Quantity

[David Berry]

Martin,

> Thanks David that's helped a lot!  Please could many of these answers go
> into the document?

Jonathan is the editor of the document.


>  >>I'd also suggest that BasicQuantity should be immutable
> [snip]

>  > I'd probably agree with BasicQuantity. CoreQuantity is another matter
>  > though. For instance, you have a StandardQuantity representing a surface
>  > brightness image of a galaxy, and this StandardQuantity contains a
>  > CoreQuantity which defines an ICRS (RA,Dec) calibration for the image
>  > (i.e. it contains an (RA,Dec) Frame, together with a Mapping between
>  > pixel coords and (RA,Dec)). Let's say a user wants to use J2004.0 FK5
>  > (RA,Dec) instead of ICRS when interacting with the Quantity. To do this
>  > they would use methods of the CoreQuantity class to change the properties
>  > of the (RA,Dec) Frame appropriately. The CoreQuantity class would also
>  > then modify its Mapping to retain the integrity of the pixel<->(RA,Dec)
>  > relationship.
>  >
>
> This suggests that the desired (J2004.0 FK5) frame is 'applied' as part
> of the interaction with a Quantity set in its own frame. Or, better, we
> should have a conversion process that creates a new CoreQuantity with
> the new (J2004.0 FK5) frame from the CoreQuantity with the old (ICRS)
> frame.  Otherwise we get all kinds of nasty problems when several bits
> of code are using the same Quantity instance, each one expecting it to
> have a certain frame.

That's certainly a possibility. It would be particularly relevant I guess
for multi-threaded access to the Quantity. But on the other side of the
balance is the expense of object creation in most OO languages.


> When I say 'properties' (not 'fields') this is a bit of software
> engineers term but does not represent storage.  It merely says 'this
> object is an assembly of these things _from the outside_ '.  As soon as
> you specify methods you specify implementation - for example, whether a
> 'set' method returns a boolean 'success/fail' or throws an exception is
> language dependent.  (eg Java implementations should throw exceptions).

Agreed, and the forth-coming draft Mapping doc does indeed include tables
of properties. My undertsanding of the proposed Quantity methods is that
they are "indicative of the sort of behaviour expected of a Quantity",
rather than being a definitive statement of an interface. Each developer
would change these methods to suit the language being used. Some things
though are definately described by methods, rather than properties (e.g.
the fwdTransform and invTransform methods in the Mapping interface in
section 6.1 of the Quantity doc).

David Berry

----------------------------------------------------------------------
Dr David S. Berry    (dsb at ast.man.ac.uk)

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 273192