[QUANTITY] Use-cases, role in larger scheme

[David Berry]

Jonathan,
         I see no problem with leaving optional components undefined
for the moment, so long as we are careful not to lock ourselves into
a corner regarding their future implementation. We followed this approach
in Starlink; in the 80's we produced the basic NDF data model, and then
added optional HISTORY and WCS components into the model in the 90's. The
important point is to make sure that the function of each component of
Quantity is clearly delineated and does not overlap the function of any
other component, either those we are designing now or those we may design
in future. For instance, if WCS is not seen as an immediate need, then
leave it out *completely* to give us maximum freedom when the time comes
to design WCS component.

What are the basic components of Quantity which you think should be
designed immediately? Presumably we need a component to store the
numerical data values in (a simple N-d array presumably to begin with),
and a component to describe what these values are (the "Units" component
in my mailings with Ed & Brian - something which can describe several
related data value systems?)

David


>
> David,
>  I understand your argument. However, it is clear from the October
> email discussion that a QuantityWithFrameAndMappings is too heavy
> an object to gain acceptance right now with a signficant fraction
> of the participants. I therefore believe we should define a
> QuantityWithUnitsAndMaybeFrameButNotMappings as our first pass on
> an agreement. There is nothing to stop us continuing to elaborate
> a QWithMappings object that would be derived from it, and when
> agreement is reached on such an object the simpler object becomes
> a special case. I think it's separable enough that we won't have
> to go back and break the simpler object once we agree on the mappings.
> But for now, I am going to ask that we make the cut for our first
> version of the object by leaving Mappings out. This is the only way
> for us to get an agreed document in a short time.
>  Jonathan
>

----------------------------------------------------------------------
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