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

[Tom Donaldson]

Hi Pierre and all,

I see many benefits in Marks proposal, but I do have some concerns.  Allowing VODML, etc. in the syntax without too much description of their semantics or usage certainly allows us the chance to evolve those sematics without frequest changes to the standard.  However, I do see a correlation between a lack of specific sematics and a lack of interoperability.  It seems to me that constructs like GROUPs were similarly loosely specified, and consequently have been largely ignored by clients due to the wide variety of possible interpretations.

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.

Thanks,
Tom


On Mar 12, 2015, at 10:27 AM, Pierre Fernique <Pierre.Fernique at astro.unistra.fr>
 wrote:

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