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

[Pierre Fernique]

Hi all,

Like Gerard, I approve Mark's proposal on all points.

Concerning prototypes, I really thank all volunteers.
In my knowledge, Tom & Gerard will try with Hubble Source Catalog and 
SDSS catalog with MAST Data Discovery Portal as client (and maybe others 
- I would be interested to try with Aladin); Omar will adapt his 
previous prototype code; and Severin has proposed the help of CADC if 
required. I hope that we could have interoperable prototype 
implementations for Sesto in order to validate or adapt our proposal, 
and after this step, to start a new VOTable process (1.4).

If there is no divergente opinion, I suggest that the dedicated 
TYPE/ALTYPE discussion will continue only on  DM mailing list and keep 
messages concerning VOTable and/or VO-DML prototypes for App cross-posting.

Best regards,
Pierre

Le 11/03/2015 13:39, Mark Taylor a écrit :
> 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/