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

[Mark Taylor]

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/