vo-dml in votable

[gerard.lemson@gmail]

Hi
May I add my few cents to Markus' comments.

> -----Original Message-----
> From: apps-bounces at ivoa.net [mailto:apps-bounces at ivoa.net] On Behalf Of
> Markus Demleitner
> Sent: Tuesday, February 17, 2015 9:04 AM
> To: apps at ivoa.net; dal at ivoa.net; dm at ivoa.net
> Subject: Re: vo-dml in votable
> 
> Hi,
> 
> On Tue, Feb 17, 2015 at 01:25:57PM +0100, François Bonnarel wrote:
> >     From the DAL point of view I think there is one only candidate so
> > far to possibly use VO-DML in DAL protocols which is in SIAV2 future
> > GetMetadata
> 
I think the proposal can relevant to DAL also when annotating TAP repositories with VO-DML metadata. In the mapping document we suggest this be done by wrapping a TAP database with a VOTable having one <TABLE> per TAP_SCHEMA.tables table and following that document's definitions. 
And if a TAP implementation is very smart it may even be able to annotate query results with proper VO-DML metadata.

In fact, any new DAL protocol built around a data model could simply use the mapping document to define its serialisations, no need at all to invent something arbitrary and providing explicit prescriptions how to infer the original data model form the custom serialisation.

> 
> >       Having in mind the coming use case of SIAV2/GetMetadata and
> > ImageDM serialisation in VOTABLE I think the new VO-DML element is
> > fine. Like Markus I don't quite understand the actual meaning of
> > "type" and "role" . To me "role" would be more about some description
> > of the relationshiops to other parts of the model while "type" is more
> > about the internal structure or content of the considered VOTBALE
> > feature.
> 
> Oh, I believe I do understand the role/type business, and indeed, I believe your
> ...
An alternative to Markus' comments that I think is somewhat simpler.
Mapping the concepts to Java, a role is an attribute in a class, a type a class/type name.
When declaring an attribute I give it a name and a type.
But when instantiating a class, I can assign to the attribute a value that is of a type that is a sub-class of the declared type.
A VOTable document annotated with VO-DML elements corresponds  to a bunch of instances of types.
IF one understands a data model exactly, one could infer from the 'role' attribute in the VODML element what 'type' to expect. But if the actual type is a sub-type of the declared one, one can use the VODML/@type to define the exact type. Similar to a casting.
Another use case for this is to assist what some people like to call a "naïve client". This is one that does *not* parse VO-DML documents when encountered with VODML annotations, but is coded to understand a particular model. Say TOPCAT, which could understand STC and use this to whenever it encounters a Position2D (or whatever name is given to it in proper STC). By having the actual type of the attribute stated in the VODML element, TOPCAT could now know that this attribute is something it understands without being required to parse the VO-DML document where it is defined.

Note, the ALTTYPE elements try to make the world even easier for such naïve clients. Namely by stating types in the super type hierarchy as well.
So when you define in your MySTC model a 'MyPosition2d extends stc:Position2d', then indicating that a certain position attribute is of type MyPosition2D does not help clients who only understand the actual STC model.
I think one should say that forcing data providers to give a complete list of all the types by which a certain role can be known is ugly.
And Markus argues that in fact this may not be necessary. Naïve clients that are STC aware  SHOULD know not only the stc:Position2D type, but also know that the roles stc:Position2d.c1 and stc:Position2D.c2 are part of that type and therefore when encountering these should be able to infer that they know the type.
So Markus argues that the type hierarchy for which the ALTTYPE elements are intended, is not needed even for naïve clients. 
And I support this argument. The consequences of this are that we would only need to vote between the following patterns:

<VODML type="yyy" role="xxx"/>

and 

<VODML><type>yyy</type><role>xxx</role></VODML>

The former being smaller, but having the possible disadvantage that any future evolution to a more complex description of role or type leads to more disturbance of the schema. I don't see any such change on the horizon, but there you are.


> >        Eventually I support Pierre idea to export the definition of
> > VO-DML element to an external document and xml schema in order to make
> > evolution of this element more easy. I guess that as long as we
> > experiment with VO-DML
> 
> I'm against that -- additional documents are, as a rule, evil.  If we have to tell
> people "well, to write a VOTable with STC annotation, read the VOTable spec,
> and then read this other spec," it's going to cost us eyeballs -- the most valuable
> resource of all.
> 
> Also, this other element couldn't be changed much more easily than VOTable
> itself either, as changing it would again break existing VOTables.  In effect, the
> interoperability problem would go from O(n)
> -- match the VOTable version -- to O(n^2) -- match VOTable and VO-DML
> version.  And in many settings, going from O(n) to O(n^2) means going from
> practical to impractical.  I suspect this is such a setting.
> 
I still agree with Markus' position.

Cheers
Gerard