Inheritance of different Q's

[David Berry]

>  Finally we need to list the pieces that are controversial even within
> the Q paradigm: should BasicQ have errors, should it be called AtomicQ, etc.
>
>  With all respect to Martin, I am not so worried about the bigger question
> of whether Q is the right model to be doing. We should do other models
> too, along the lines Martin suggests, and perhaps they will turn out
> more useful in the end. I don't think we can settle that argument in advance.

Maybe a compromise would be to keep StdQ, CoreQ (and probably BasicQ)
but to do away with the inheritance relationships between them. So we
would have:

1) CoreQ: a rule for getting values for a potentially vector-valued
Quantity. Aggregates a Frame and a Mapping (or ValuesList). Does *not*
inherit from Frame or BasicQ or anything else:

  CoreQ {
     Frame
     Mapping or ValuesList
  }


2) StdQ: >*USES*<  CoreQ (but does not inherit from CoreQ) to describe
a Quantity with optional axes and and alternate data representations:

  StdQ {
     CoreQ[] values;  (a list of CoreQ's holding the values in
                       different representations. This list would often
                       have a length of one - i.e. only one data
                       representation).
     CoreQ[] WCS;     (a list of CoreQs describing the coordinate systems
                       which can be used to describe the position of
                       elements within the "values"  CoreQ)
  }

Any problems with this?

David