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

[gerard.lemson@gmail]

Hi Francois

> -----Original Message-----
> From: apps-bounces at ivoa.net [mailto:apps-bounces at ivoa.net] On Behalf Of
> François Bonnarel
> Sent: Sunday, March 15, 2015 11:46 AM
> To: Mark Taylor
> Cc: <apps at ivoa.net>; Laurino, Omar; <dm at ivoa.net>
> Subject: Re: regarding ALTTYPE [was RE: vo-dml in votable]
> 
> Hi all,
>       From DAL point of view: current DAL clients (including those
intended for
> SIAV2.0, DataLink and AccessData in a very close future) are "naive"
clients in
> the sense of OMar's definition (from fisrt VO-DML mapping document).
> Sophisticated or Guru clients are applications like IRIS or various VO-DML
> prototypes which are still under iterations.
>        IN the future SIAV2.1 clients could be VO-DML aware and will have
to
> "know" about ImageDM for example. BUt it's not yet to, be available
> tommorrow.
Interesting to bring up the case of DAL clients and DAL services in general.
We discussed these cases during the tiger team, in particular that DAL
services might for a while well choose to be DM neutral and define their own
ad hoc serialization for some time. And note, if DAL clients are not DM
aware, they do not even qualify as naïve.
I think it would be very nice if DAL services could be written in such a way
that the data models they expose would be part of the result format and
simply be serialized in the manner proposed in the mapping document. If that
were the case some DAL clients might choose to be naïve, knowing only the
standardized ImageDM for example. Others might become sophisticated, being
able to understand for example that a HubbleImageDM was extending that
standard. 

>       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.

Just an obvious proviso to take into account.

Cheers
Gerard


> Cheers
> François
> 
> Le 12/03/2015 18:18, Mark Taylor a écrit :
> > Tom,
> >
> > On Thu, Mar 12, 2015 at 10:41 AM, Tom Donaldson<tdonaldson at stsci.edu>
> wrote:
> >
> >> I think this flexible approach may be fine, but I'd be more
> >> comfortable if we commit to trying to specify the semantics
> >> relatively soon as opposed to leaving them permanently flexible.  If
> >> our intention is to allow a placeholder element where two peers can
> >> exchange whatever they like, then we should add a generic element to
> >> the syntax expressly for that purpose, but in a case like this where
> >> we hope that multiple clients can understand the same metadata from
> >> multiple resources, then I think we should work to nail it down.
> > You're right that there's a tension between flexibility and
> > interoperability.  But probably we don't disagree.
> >
> > To clarify: I wasn't suggesting a free-for-all on VODML semantics,
> > just a separation of concerns, so that the syntax is defined in the
> > VOTable document and the semantics elsewhere (the VODML mapping
> > document I think, but anyway some place under control of the VODML/DM
> > experts).
> >
> > The advantage from the VOTable point of view is that we can keep it to
> > one, uncontroversial, change to the VOTable document which is
> > (hopefully) unlikely to need future revision.
> >
> > The advantage from the VODML point of view is that we can get going on
> > the required updates to the VOTable document now/soon, rather than
> > having to wait until all the prototyping has been done and the
> > disagreements ironed out before starting that process.  The VOTable
> > infrastructure can be in place and standardised (or on the way to it)
> > which will help to support the prototyping.
> >
> > Obviously, the semantics as well as syntax has to be agreed eventually
> > in order for this to deliver interoperability.
> > The decoupling of timescales does provide the opportunity/danger of
> > postponing that agreement, so some degree of discipline will be
> > required.  Soon is certainly good!
> >
> > In any case I would have thought that the VODML mapping document is
> > the logical place to describe the details of how to use whatever
> > VOTable machinery is in place.  Given that, avoiding the specific
> > multiplicity restriction in the VOTable schema but mandating it (or
> > not) in the VODML mapping document doesn't seem like a major cost.
> >
> > On Thu, 12 Mar 2015, Laurino, Omar wrote:
> >
> >> I agree with Tom. That is why my proposal was to start prototyping
> >> with a scheme that *does not* allow multiple TYPEs, as this seems to
> >> be the consensus. If during the prototyping phase, when we probe the
> >> relevant use cases we find out that we actually need multiple TYPEs
> >> we can indeed add that to the draft, but with a clear semantic meaning.
> > That's not inconsistent with what I had in mind.  My suggestion was
> > just that the multiplicity of TYPE (single unless it turns out that we
> > need something different) be defined semantically in the VODML mapping
> > document rather than enforced syntactically by the VOTable standard
> > and schema.
> >
> > Mark
> >
> > --
> > 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/
> >