[QUANTITY] Quantity "arguments"

[Doug Tody]

On Fri, 14 Nov 2003, Steve Lowe wrote:

> Doug Tody wrote:
> > On Fri, 14 Nov 2003, Steve Lowe wrote:
> > 
> >>I think what is missing is requirements.
> > 
> > 
> > Component-level requirements are needed, but we need to back up one
> > step further and define an architecture which lays out what the data
> > model components (such as quantity) are, and what their role is in some
> > larger scheme.  What keeps happening in these discussions is that people
> > have very different views of the scope or role of a component and start
> > trying to include functionality which belongs elsewhere.  Pretty soon
> 
> I actually meant higher-level (system-level?) requirements, which comes 
> a step before even that architecture.

I addressed this somewhat in my response to Brian.  Basically we already
did this - the initial use-case analysis and basic architecture was done
over a year ago.  It is probably hard for those who weren't in the meetings
back then to follow all this.


> I agree with you about people trying to include functionality that 
> belongs elsewhere. In part, I think this stems from the attempts to 
> design one component at a time. For every desirable feature, you have to 
> ask *whether* to include it instead of *which* component does it belong in.

Exactly so.  This issue extends all the way up to the applications level.
There is much that we should not attempt to do in the VO framework at all,
but should leave to the people writing analysis applications.


> > what started out as a simple component has morphed into some grand vision
> > (more likely several) that encompasses far too much.  It is possible to
> > make some progress without a fully developed architecture, but only if we
> > focus on defining some simple components for which we have some immediate
> > use in mind.
> 
> But I don't think defining *just* the simple components buys much---why 
> bother making detailed decisions about little components when we're not 
> sure what the big components need to do yet?

The top-down refinement process (which is most of our current effort) is
addressing that angle.

The primary motivation now for component data models is 1) we have
identified some things we need now at the current stage of refinement,
and have an actual use for (e.g., for data characterization), and 2) it
will be useful to try to do these in a more formal, structured way, as in
the process we will work out how to define formal data models and start
to learn how to aggregate and associate them to model more complex entities.

	- Doug