[QUANTITY] Data Model for Quantity v0.5

[Alberto Micol]

Data Model for Quantity v0.5

I keep it as short as I can, and go directly to the main comments.
Many other detailed comments are available (read: scribbled onto the 
print out).


0.- Overall, I was expecting a document describing what a quantity is,
    how a DM on a quantity could help out in various scenarios, how 
people will solve
    otherwise unsolvable problems by using it. Hence I would have liked 
to see
    what are the problems to be addressed, and what are the suggested 
solutions.
    And all that, much before discussing "classes", "instances", 
"interfaces", etc.

0a.- Context
    A use case mentions: "Describing a scalar value and its context"
    I found weak the way the context gets described, since it relies 
completely on a UCD.
    (In that sense, the model is not very far from the "FIELD" 
definition in the VOTable)

0b.- Compatibility issue (context-related)
    How do I know whether two quantities (fetched from different providers)
    are "compatible"? Of course "compatibility" first needs a definition ...
    In the document such problem is mentioned, but not addressed, and I 
think it is
    a problem which has probably the highest priority, if we want to 
exchange quantities.

    UCDs are referred to, but "compatibility" is a different matter; 
example:
    I got two quantities, one is the isophotal diameter of a galaxy at 
the limiting
    surface brightness of 25 Bmag/arcsec2 the other is the diameter but 
at a limiting
    24Bmag/arcsec2. They have the same units, and, correct me if I'm 
wrong, the same UCD.
    But they are incompatible. I cannot take the average of those two 
quantities,
    'cause they physically mean something else.

0c.- UTYPE is not mentioned (could be the solution to the 
compatibility/context issue)
    UTYPE is thought to be the solution for "compatibility" issues
    (in the VOTable context at least). Maybe the Quantity DM is not the 
right place
    to define this, but then, where?


1.- Language English and OO-speak are intermixed
    I love the RM (registry) document; it's in pure english, hence
    it is not implementation/philosophy-driven.
    If you cannot really abstein from using terms like "classes, 
interfaces, instantiations"
    at least define them in the introduction.   

2.- UCDs are briefly mentioned here and there; UCDs and their relationship
    with the Quantity DM probably require more attention, and deserve a 
full chapter.
    Only then we will be able to identify flaws or unnecessary redundancy.

3.- When speaking of coordinate systems, what's the relationship with STC?


4.- Requirements (chapter 3): could you group/highlight different kind 
of requirements?
    I can see High Level Quantity reqs, Architectural reqs, Tool reqs ...


5.- May I propose to introduce all the various quantities 
(Core/Basic/Standard)
    before they get referred to? It would greatly improve the 
readibility of the document.


6.- In the example 2 on page 26 the Magnitudes are given without 
reference to a bandpass,
    and its zeropoints. How would you see that done properly?


7.- In the various examples various units are given (eg, "km s^-1", etc.)
    We should have a standard set of allowed units and a standard set of 
operators.
    At CDS (or is it the standard SI?) a blank is not allowed, 
multiplication is a dot "."
    exponent is just concatenated, etc.: the right spelling would be 
"km.s-1"
    We have to have a common set of rules and names to interoperate. 
This should
    be mentioned in the document.


Moral: it's easier to criticise a document than writing it ... :-)

Alberto