[QUANTITY] Suggested method of work to maintain progress. (was: Re: [QUANTITY] The discussion so far)

[Brian Thomas]

	Jonathan,

	Thanks for the summary. It shows (to me) that we have made
	some progress on the quantity, particularly in demonstrating that 
	there is some cohesiveness in outlook and that we all can approach this
	in a fairly open manner. I'm encouraged. Nevertheless, I think we
	are reaching the limit of progress with our current "shootout" 	
	style of interaction on the mailing list. I'll illustrate my point below.

On Thursday 30 October 2003 10:27 pm, Jonathan McDowell wrote:
> Quantity Discussions Oct 2003
> [snip]
>
> Does Q support multi-dim arrays with links to other Q's as axes?
>  example: Flux(Wavelength)
>  Thomas Oct 29: yes
>  Plante: no, higher level object to connect data Q with axis Qs
>  McDowell: I agree with Ray, this should be a higher level object.
>   Q should be the values associated with a single UCD (not counting
>   modifiers like error, quality), and anything connecting two UCDs
>   should not be in Q.
>  (admittedly our CfA DataContainer object does do this WCS stuff,
>   but I think we are trying
>   to keep Q a little simpler.)

	I wonder to what effect do we gain by keeping this "simpler" or
	(to be fair) by making it more "complete". Many argue one way and
	a few the other, but I see no actual rationale for either. The use-cases
	and requirements should drive the design. Implementation is 
	just the aftermath of all that and not the driver. I am as guilty in this as others.

	Thus, I suggest that we table our "preferences" for implementation of
	the design for the time being and focus on completing a basic set of use-cases 
	and requirements for the QUANTITY. Lets *finish* arguing that, then the design 
	will be much  easier to agree on (and it will help to delineate the differences between 
	the terms we all bat around like "quantity", "measurement", "mapping", "matrix", 
	"atom", etc).

	And for those skeptics out there that believe no progress has been
	made, we *do* have some quantity requirements on the web page
	I mentioned. At Ray's gentle suggestion, I will be converting these
	to a group editable document that will go on the Twiki. Can we 
	set a schedule for QUANTITY use-case, requirements gathering?

	I can either start another document on the Twiki for use-cases or make a 
	section in the requirements document.

	The Twiki document will let everyone put in their use-cases/requirements, 
	with a "first-cut" deadline of end of  next week (Friday, Nov7). The following 
	week (Nov10-17) we can hash out what really belongs in these documents
	(that is, what  is/isn't a requirement or relevant use-case). The remainder of 
	November would be enough (I think) to get a basic quantity design based
	on those principles.

	Thoughts? Any suggested modifications? Or do you all like the current 
	direction of the progress?

	Regards,


		-b.t.

-- 

  * Dr. Brian Thomas 

  * Code 630.1 
  * Goddard Space Flight Center NASA

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