[QUANTITY] our view of holding qualities in quantities. (Was: Re: [QUANTITY] Requirements and apology

[Brian Thomas]

On Thursday 30 October 2003 08:50 am, David Berry wrote:
>
> The other issue is that Ray's model doesn't include a QUALITY component.
> The two options are 1) to put quality information "inside" the quantity as
> I suggest, or 2) to put it "along-side" the Quantity (that is as another
> component of the object which contains the Quantity). I think a useful
> working principle for a Quantity would be that you should be able to
> interpret and use it independantly of its parent structure. That is, if
> you extract a Quantity from its parent structure you should still be
> able to make use of it. This would argue in favour of putting the QUALITY
> information *inside* the Quantity.

	I believe what you are saying is more or less a widely held view, but
	I can affirm that we, at least, also agree (more or less). Our take is this:
	 in our model.. a general purpose hook exists to describe the "accuracy" 
	of the value(s) held by the quantity. This accuracy hook is an interface
	which collects together classes that  "errors" and "quality".

	So, the 'hook' or pointer *is* in the quantity *but* the interface for that hook
	is defined in another package where the "quality" (which we consider is 
	an abstract class/interface) is defined. That "quality" package is also a 
	"base" level package alongside "quantity" (and "transform/mapping/coordinateSystem"),
	but is left for higher level component level for actual qualities to defined 
	concretely. This allows flags to have attached namespace/package with 
	helps define their scope/applicability.

	Regards,

	=b.t.

-- 

  * Dr. Brian Thomas 

  * Code 630.1 
  * Goddard Space Flight Center NASA

  *   fax: (301) 286-1775
  * phone: (301) 286-6128