ivoa: DM type system

[Laurent Michel]

Dear all,

I agree with Markus, having LITERAL @dmtypes compliant with VOTable datatypes would be valuable.
Unfortunately, LITERAL @dmtypes are not necessarily in the ivoa name space (ivoa:xx).
They can refer to dataTypes defined into the model. This is the case for ENUM literals e.g..
The following example is taken out from a mapping example written by MCD.

    <LITERAL dmtype="coordsys:domain.spatial.StdRefFrame" value="ICRS"/>

It is valid, however it forces clients to do some inferences. Even if we consider that LITERAL as a String by default, we cannot 
not make sure that the value (ICRS e.g.) is valid against the model.

Being playing with the new mapping, I would say that this is a more general issue:
1) The model specifies types.
2) The VOTAble data have their own types
3) The mapping maps both one to one without checking that types match.
As before, we rely on the client skill to solve conflicts.

Finally, I do not think that renaming ivoa types as VOTable datatypes will help that much.
This is must be clarified in the standard by the way

Cheers
LM

Le 11/04/2017 à 15:57, Markus Demleitner a écrit :
> Dear DM,
>
> I feel mildly bad for bringing another issue up, in particular since
> it really concerns VO-DML, and that this late into its RFC.  But it's
> the kind of thing you notice when you start to play with stuff, and
> in this case it's also because of the new annotation scheme showcased
> by Mark in his mail
> http://mail.ivoa.net/pipermail/dm/2017-April/005519.html.  I've made
> a corresponding note on the RFC page
> http://wiki.ivoa.net/twiki/bin/view/IVOA/VODML1RFC, but since most of
> you probably won't see it there, I take the liberty of copying it
> here:
>
> [With Mark and Tom's proposed serialisation I] noticed that with it
> the types in the ivoa: DM that is part of the VO-DML spec become
> actually relevant outside of the lofty heights of drawing diagrams:
> VOTable writers will have to infer them for writing LITERALs.
>
> Only then did I realise that ivoa: really defines another type
> system. Now, DaCHS already translates between a gazillion type
> systems (among others, postgres, python, TAP, VOTable, FITS, numpy,
> XSD). Based on this, you could say it doesn't really matter.
>
> But another type system still is another source of bugs, impedance
> mismatch ("oh boy, what do I translate rational into?"), and
> annoyance for our users ("What, LITERAL has a dmtype attribute that's
> using something that has nothing to do with PARAM's @type?"). Is it
> really, really, really necessary that ivoa: does not just re-use the
> VOTable type system?
>
> Since a thorough investigation of this matter might slow down the
> RFC: How difficult would it be to pull the ivoa: DM out of VO-DML and
> have a document of its own for it? That'd also give us a bit more
> time to think about Quantity; also, I think our future selves will be
> grateful if they don't have to re-issue VO-DML itself when they just
> want to fix ivoa:...
>
>         -- Markus
>

-- 
jesuischarlie/Tunis/Paris/Bruxelles/Berlin

Laurent Michel
SSC XMM-Newton
Tél : +33 (0)3 68 85 24 37
Fax : +33 (0)3 )3 68 85 24 32
Université de Strasbourg <http://www.unistra.fr>
Observatoire Astronomique
11 Rue de l'Université
F - 67200 Strasbourg