ivoa: DM type system

[Markus Demleitner]

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