Utypes 0.4 comments

[Mireille Louys]

Hi Norman, Hi all,

Thanks for your comments on the draft.
My answers are inserted in your text below.
I may have misunderstood some of your points .
Please do not hesitate to correct me if this is the case .

Cheers , Mireille

Norman Gray wrote:
> Mireille, hello.
>
> Here are some comments on v0.4 of the utypes draft at <http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/Utypes>.
>
>
>
> My only real concern is that the document could give the impression that utypes are more complicated than (I believe) they in fact are.  This is because the draft specifies more than appears to me to be necessary.
>
> For example, you mention Object Oriented modelling at the beginning of section 2.2, and in section 3.1 say "Models are built following object oriented programming principles. They are represented in UML".  Is this necessarily a given?  Obviously, the Characterisation DM is in UML, but the SSA DM is described in text with an XSchema, STC is defined using an XSchema, and FITS-WCS (for example) is described in text (presumably we wouldn't want to exclude FITS-WCS in principle from retrospectively defining utypes).  This is not to say that object-orientation is a bad thing (of course), but that it's not clear if anything is being gained by the apparent restriction to UML.
>   
UML representation is a requirement for an IVOA DM.
Char and Spectrum have a UML representation .
SSA as a protocol re-uses the utypes generated from Spectrum DM.
Small consistency pbs are currently being corrected for that.
FITS -WCS will be part of the Observation DM.

Building up a model in UML enforces the consistency of the various 
models the IVOA has to tackle.
This is a framework that helps to bind the different parts together and 
vital now when we need to cover the general case of an observation and 
bind together Photometry , Characterisation , and WCS representation.

Without this frame work , there is a risk of divergence and parallel 
work that already occurs .

Simple models do not need this , and can be developped without the 
object oriented view , but then re-using parts of existing models is a 
nightmare.

I think we can simplify this section if you think this is too computer 
science oriented.

I guess the targeted audience for this draft is , the developers and the 
data providers.
Wether Utypes should be exposed to the final users is a controversial 
issue at the moment in DM and other WGs.

> In a similar vein, the discussion in section 4 defines a syntax for utypes, composed of models, packages, classes, references and collections.  This is starting to become intricate, and making the syntax this specific suggests that it is intended to be parsed, which goes against what I believe to be the decided unparseability of utypes.
>
>   
With a (utype, value list) describing an observation, I want to be able 
to regenerate a set of Java classes f.i. , that represents this 
particular instance of my observation.
So the nested structure must be present in the Utype string.
> Similarly again, Section 6, on "Generating Utypes from UML data models via their XML representation" might possibly be overspecification.  If utypes are indeed unparseable pointers to items within data models, then they could in principle be named simply 'utype1', 'utype2' and so on, without any technical ill-effects.  That would be a poor idea on usability grounds, however, because that would make any system using them hard to debug.  Thus some mechanism such as that in Section 6 would be highly recommendable.  However the text in that section seems to _require_ that utypes be generated using this specific mechanism, using a particular representation (XMI) of a particular modelling language (UML).
>
>   
Ok, this can be clarified here, that this mechanism to generate utypes 
is a framework to easily maintain the utype list, and the documentation. 
This corresponds to how we would maintain Utypes .
> I hope these comments are helpful.
>
> Best wishes,
>
> Norman
>
>
>   


-- 
--------------------------------------------------------------
!! Please notice my phone number has changed!!
 Mireille LOUYS          mailto: mireille.louys at unistra.fr
                                      
L S I I T                       &     CDS,
Ecole Nationale Superieure            Observatoire de Strasbourg    
de Physique de Strasbourg,            11, Rue de l'Universite
Boulevard Sébastien Brant, BP 10413   67000 STRASBOURG
67412 ILLKIRCH Cedex       	      Tel: +33 3 68 85 24 34
---------------------------------------------------------------