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

[François Bonnarel]

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