[QUANTITY] why we should have string values in quantity

[Ray Plante]

On Mon, 3 Nov 2003, Jonathan McDowell wrote:
> Indeed, in my mind Q is something
> which can be used to represent FITS keywords and FITS table columns,
> both of which are objects which are very like our discussions of Q
> and which one often wants to perform metadata operations on independent
> of whether they are string or numeric valued. 

Like what?  get/set/display/...?

> This real world 
> situation - that the thing in our data now which most closely maps
> to Q is something which can be either numeric or string valued and
> which shares common metadata and methods - convinces me that having
> Q support strings, 

I don't want to say that you shouldn't have a common set of methods for 
handling FITS keywords or table columns (or that you can't reuse the 
software you already have to support this).  I would suggest, however, 
that what you are trying to model is something else--like a table value.  
My concerns are:

  *  In my view, the data models are not about defining storage mechanisms 
     but rather attaching semantics to data.  Are you breaking the 
     semantics of a "quantity" by trying to support string values?  

  *  Is this more a matter of putting a particular view on top of the 
     quantity semantic model?  (i.e. viewing a quanitity as a table cell)

  *  even the simplest model we've discussed for a Quantity is too complex 
     to define a unique mapping to FITS keywords/table cells.  What is 
     needed instead is a table model that allows one to specify how a 
     Quantity or some label (i.e. string-based value) maps into the table 
     using the "pointer into a data model" (i.e. the function of a utype 
     parameter). 

hope this helps,
Ray