ivoa: DM type system

[Markus Demleitner]

Hi Gerard,

On Wed, Apr 19, 2017 at 05:02:37PM -0400, Gerard Lemson wrote:
> On Wed, Apr 19, 2017 at 3:56 AM, Markus Demleitner <
> msdemlei at ari.uni-heidelberg.de> wrote:
> > I'd much prefer, too, if PARAMrefs and FIELDrefs could make a return
> > there.  Later implementors will not give a damn about the history of
> > the annotation.  They'll just curse us for having multiple elements
> > (PARAMref and CONSTANT, FIELDref and COLUMN) that do the same thing,
> > just in different places.
> >
> > I am actually against reusing these VOTable types in the VODML annotation
> as their content is quite different.
> Wrt CONSTANT and ParamRef, and COLUMN and FieldRef, apart from dmtype, the
> vodml mapping versions inherit OPTIONMAPPING from VODMLPrimitive. The
> votable elements have ucd and utype which we explicitly have no place in a
> VODML annotation.

Well, I believe @utype should be deprecated everywhere once we've
figured this DM buisness out, and just because @ucd *can* be there
doesn't mean it has to be used or has any meaning.  That's for the
mapping document to define, no?

> I still think that anyone who starts coding against the VODML annotation
> part of the VOTable will write completely new code and should not be scared
> that there are new names on elements that may superficially seem similar.

I certainly hope that's not going to be the case.  As I said,
according to the current plan, the VODML element will contain very
basic annotation, and essentially all existing code will have to deal
with it one way or another if it wants to stay relevant going away
from J2000.

So, migration matters.  A lot.  We've botched the migration from
COOSYS to STC annotation for a number of reasons, the indication that
STC annotation somehow "isn't part of the spec" being a major one.
Let's not make that mistake again and make it clear that VOTable
without these annotations simply is not going to usefully work in the
future.

> I think one might reverse the argument, expecting(well, hoping?) that
> future implementors will not have to deal with GROUPs and their paramrefs
> and fieldrefs anymore, because VODML will replace their use.

We *could* deprecate and replace them, but is a simple re-christening
and getting rid of @ucd actually worth the ensuing maintenance
trouble?

> So, so far my conclusion is that
> 1) We SHOULD add VOTable features identifying the datatype of LITERALs in a
> VODML independent manner. The consequence of this is that we likely have to
> add the VODML annoatation elements inside the VOTable schema.

Since we certainly cannot deprecate PARAM to replace it with LITERAL,
I'm starting to be even more firmly convinced that the mapping should
use PARAMs instead of LITERALS.

If you say there's too many required attributes on PARAM -- well,
that's @datatype, @name, and @value.  @datatype and @value you need
anyway, and as for @name, I suppose VOTable could easily be changed
to not require it (though I think there'd be nothing wrong to come up
with a sensible rule to generate a name).

That PARAM can do a lot more isn't an actual problem; if the mapping
spec doesn't give any meaning to it, that's it (and perhaps these
things might come in handy later; there's a reason they're in).

> 2) We MAY wish make the dmtype attribute optional on all instances.

I'm pretty sure that's a good idea.  It makes the annotation more
compact (always a good thing) without taking away information for
non-validating clients.  Validating clients will have to have the
VO-DML anyway, so they can, in the non-cast case, work out the dmtype
without noticable extra effort.


So, I guess my main message here is: Either re-use PARAM, PARAMref
and FIELDref (preferred) or deprecate them in favour of your new
elements (not so sure about GROUP, though).  If both are in the same
spec, it'll look odd, feel bad, and thus hinder takeup.

         -- Markus