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

[Mark Taylor]

Omar et al.,

I still don't know the Right Answer in modelling and usage terms here;
as others have said, prototyping is probably the way to answer that.

On Tue, 10 Mar 2015, Laurino, Omar wrote:

> P.S. In my previous email I might have mixed up the VOTable change
> proposals, but that should have been clear from what I argued. I believe 4c
> is the only proposal that does not have ALTTYPE but allows for multiple
> types. There seems to be consensus that we can do without the multiple
> TYPEs, so my vote is for a slightly different version of 4c where the TYPE
> multiplicity is bound to 0..1. This can be turned into an open multiplicity
> in the future if we think we need multiple TYPEs afterall.

Given that there is still active debate among the experts about
the desirability of multiple (ALT)TYPEs, from the point of view
of VOTable maintenance and stability it would seem sensible to
use something like 4c that does not shut down the possibility
of multiple TYPEs.  Regarding Omar's suggestion of a modified 4c
with multiplicity 0..1, I would argue that this additional
multiplicity restriction ought not to be written into the VOTable
schema/standard itself; it would be very annoying to have to
issue VOTable 1.5 one day just in order to change the value
of a maxOccurs xs:element qualifier.

Following that reasoning the VOTable (1.4?) standard could just
define the elements VODML, TYPE and ROLE (multiple TYPEs allowed)
without too much description of their semantics or usage, and point
to the VODML mapping document for the details; that mapping document
could then supply additional requirements or advice about TYPE
multiplicity.  VOTable could then be somewhat insulated against
future changes in the requirements or usage patterns of VODML
metadata.

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/