regarding ALTTYPE [was RE: vo-dml in votable]

[gerard.lemson@gmail]

Hi Laurent
> Hello everybody,
> 
> Reading the last threads I do not see any formal constraint on the
modeling
> space enclosed into the VO-DML serialization.
> I may have missed something, but I'm understanding that VO-DML is not only
> intended to carry the mapping of VO models in DAL responses but that it
should
> support any sort of DMs,
> 
> I think that clarifying this point could help contributors (myself at
> least) to both figure out what are the stakes of this open though a little
bit
> obscure discussion about ALTTYPEs and to have an idea about where to put
the
> cursor between the completeness of the VODML specification and a short
term
> issue of a first recommendation usable by both client and service
implementers.
> 
> For instance, it is clear that considering models as abstract entities
which are not
> particularly related to some specific background will lead us to tackle
with all OO
> facets whereas limiting the scope of the considered DMs to some
composition
> or derivation of already defined VO quantities could allow significant
> simplification in the serialization process.
> 
My first response would be that the VODML elements proposed to be added to
the VOTable spec will identify elements from a VO-DML data model (i.e. the
old utype idea). *How* this annotation is to be interpreted and the
rules/restrictions that define valid annotation patterns is the subject of
the "mapping document". The main discussion theere is how to use GROUPs and
their child elements to represent the types etc form the VO-DML data model.
It is precisely the fact that we have in VO-DML a formally defined
meta-model for data models that we can define such mapping patterns and
rules.
There is a version of the mapping document on volute
(https://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/MappingDMtoV
OTable-v1.0.docx, earlier versions in the same folder) that is still written
under the assumption we'd use the utype attribute. I am in the process of
updating that document, a process that includes updating the examples to
have the <VODML><ROLE/><TYPE/></VODML> design. The question on the
multiplicity of VODML/TYPE and eventual other minor additions to that
element are not so important for that next draft.
But I think we must be allowed to keep some options open to change the
request for change on VOTable based on the discussions on that mapping
specification. For it is that document that should guide the VOTable
additions, not the other way around.

Cheers
Gerard

> Joining the discussion very late and being not a guru, I hope not to be
too much
> naive =:)
> 
> Bye
> Laurent
> 
> NOTE: Something went wrong with this mail, This mail has been sent 3 times
on
> APPs in addition with a draft, but not on DM/DAL.
> Sorry
> 
> Le 16/03/2015 15:49, Mark Taylor a écrit :
> > On Mon, 16 Mar 2015, gerard.lemson at gmail wrote:
> >
> >>>        The important point is to keep the changes in VOTABLE as
> >>> minimal and
> >> rare
> >>> as possible. I agree that the debate between "unique Types" /
> >>> "multiple
> >> Types" is
> >>> still open and should be arbitrated by experience with VO-DML-aware
> >> clients
> >>> and prototypes.
> >>>        In these conditions and after considering all options I
> >>> finally
> >> follow Mark's
> >>> proposal.
> >>>        This will allow some kind of experimental flexibility, freeze
> >> VOTABLE changes
> >>> rather soon and allow changes in VO-DML detailed syntax to be tuned
> >>> in the coming monthes/years.
> >> I am starting to come back a bit on what I thought Mark was
> >> proposing. I do not know for sure whether we can guarantee that any
> >> proposed VOTable change can be frozen until we have more progress on
> >> the mapping document itself. I think I can guarantee that all
> >> annotation will be confined to VODML elements on some VOTable types,
> >> but the precise details of this element may still have to change a
> >> bit. In particular, simply setting maxOccurs=unbounded on VODML/TYPE,
> though a useful step, may not be the end of the discussion.
> >
> > If that's the case, I'm not sure I'm so keen on my proposal either.
> >
> > --
> > Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
> > m.b.taylor at bris.ac.uk +44-117-9288776
> > http://www.star.bris.ac.uk/~mbt/
> >
> 
> --
> ---- Laurent MICHEL              Tel  (33 0) 3 68 85 24 37
>       Observatoire de Strasbourg  Fax  (33 0) 3 68 85 24 32
>       11 Rue de l'Universite      Mail laurent.michel at astro.unistra.fr
>       67000 Strasbourg (France)   Web  http://astro.u-strasbg.fr/~michel
> ---