[QUANTITY] Data Model for Quantity v0.5 - more on Quantity vs assembly

[Martin @ ROE]

Brian Thomas wrote:
>>
>>- Don't have a Q container model at all, every piece of data is its
>>own class with a corresponding definition in the schema. (Hill)
> 
> 
> 	To be clear, this approach means to throw away doing any quantity at all.

Er well that's a little misleading...   To be clear it means that 
quantities are assembled from re-used components with a specific purpose 
in mind.  ie, a quantity that describes a radio flux will be related to 
one that describes an x-ray flux, but is not related (in a class 
diagram) to a quantity that describes the size of my shoe.

> 	In the end, this will be very complex model with no reusable parts. The supporting
> 	library is likely to be quite large and complex and difficult to implement and
> 	understand and maintain.

No! We are now in the area of computer science rather than software 
development, and the impact of decisions we make on object models do not 
always have the 'common sense' results.

The issue is about how things are 'reused' not whether we reuse them. 
Using assembly/aggregation rather than inheritance means we 'free up' 
the ways we can develop things from existing things.   We need this if 
we can be sure we can cope with things we haven't thought of yet.  Our 
supporting libraries can then be sets of packages, rather than being 
large monolithic codesets that have to be created in a single step to be 
of any use at all.

> 	I don't see how this will be extensible either as it amounts to proscibing a universal model
> 	(or set of models) for all, from which nobody can extend without breaking the functionality 
> 	of the VO as a whole. 

In fact it is the other way around.  Single inheritance models are 
extremely restricting - if down the road we find we need to change 
something in Frame for example, we risk breaking every single VO 
quantity in the whole model...

>       I vote "no!" for this. Proponents: please outline how you can satisfy 
> 	VO needs with this kind of approach.

In contrast to my comments above: any particular assembly is not an 
attempt to solve the whole VO needs.  This is its strength and 
Quantity's weakness; we can build quantities for particular purposes. 
This makes agreement much easier and code libraries relatively 
independent.  Where models overlap, we share models - such as the STC.

The STC is a classic example of something already happening this way; we 
have a common representation & model, and we *include* it in our model. 
This is the reuse I would like to see, and without which it is going to 
be harder, not easier, to build an interoperating VO.


-- 
Martin Hill
Software Engineer, AstroGrid (ROE)
07901 55 24 66