<div dir="ltr">Hi,<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 12, 2015 at 10:41 AM, Tom Donaldson <span dir="ltr"><<a href="mailto:tdonaldson@stsci.edu" target="_blank">tdonaldson@stsci.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
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.<br>
<br></blockquote><div><br></div><div>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.</div><div><br></div><div>Omar.</div><div><br></div><div>P.S. I am not sure I understand the suggestion that the ALTTYPE (I would call it multiple TYPEs as nobody actually is in favor of ALTTYPE) discussion should continue on the DM list only, as this discussion does not affect data modeling but the VOTable schema and the implementations.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On Mar 12, 2015, at 10:27 AM, Pierre Fernique <<a href="mailto:Pierre.Fernique@astro.unistra.fr">Pierre.Fernique@astro.unistra.fr</a>><br>
<div class="HOEnZb"><div class="h5"> wrote:<br>
<br>
><br>
> Hi all,<br>
><br>
> Like Gerard, I approve Mark's proposal on all points.<br>
><br>
> Concerning prototypes, I really thank all volunteers.<br>
> 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).<br>
><br>
> 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.<br>
><br>
> Best regards,<br>
> Pierre<br>
><br>
> Le 11/03/2015 13:39, Mark Taylor a écrit :<br>
>> Omar et al.,<br>
>><br>
>> I still don't know the Right Answer in modelling and usage terms here;<br>
>> as others have said, prototyping is probably the way to answer that.<br>
>><br>
>> On Tue, 10 Mar 2015, Laurino, Omar wrote:<br>
>><br>
>>> P.S. In my previous email I might have mixed up the VOTable change<br>
>>> proposals, but that should have been clear from what I argued. I believe 4c<br>
>>> is the only proposal that does not have ALTTYPE but allows for multiple<br>
>>> types. There seems to be consensus that we can do without the multiple<br>
>>> TYPEs, so my vote is for a slightly different version of 4c where the TYPE<br>
>>> multiplicity is bound to 0..1. This can be turned into an open multiplicity<br>
>>> in the future if we think we need multiple TYPEs afterall.<br>
>> Given that there is still active debate among the experts about<br>
>> the desirability of multiple (ALT)TYPEs, from the point of view<br>
>> of VOTable maintenance and stability it would seem sensible to<br>
>> use something like 4c that does not shut down the possibility<br>
>> of multiple TYPEs. Regarding Omar's suggestion of a modified 4c<br>
>> with multiplicity 0..1, I would argue that this additional<br>
>> multiplicity restriction ought not to be written into the VOTable<br>
>> schema/standard itself; it would be very annoying to have to<br>
>> issue VOTable 1.5 one day just in order to change the value<br>
>> of a maxOccurs xs:element qualifier.<br>
>><br>
>> Following that reasoning the VOTable (1.4?) standard could just<br>
>> define the elements VODML, TYPE and ROLE (multiple TYPEs allowed)<br>
>> without too much description of their semantics or usage, and point<br>
>> to the VODML mapping document for the details; that mapping document<br>
>> could then supply additional requirements or advice about TYPE<br>
>> multiplicity. VOTable could then be somewhat insulated against<br>
>> future changes in the requirements or usage patterns of VODML<br>
>> metadata.<br>
>><br>
>> Mark<br>
>><br>
>> --<br>
>> Mark Taylor Astronomical Programmer Physics, Bristol University, UK<br>
>> <a href="mailto:m.b.taylor@bris.ac.uk">m.b.taylor@bris.ac.uk</a> <a href="tel:%2B44-117-9288776" value="+441179288776">+44-117-9288776</a> <a href="http://www.star.bris.ac.uk/~mbt/" target="_blank">http://www.star.bris.ac.uk/~mbt/</a><br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Omar Laurino<br>Smithsonian Astrophysical Observatory<br>Harvard-Smithsonian Center for Astrophysics<div><font color="#999999">100 Acorn Park Dr. R-377 MS-81</font></div><div><font color="#999999">02140 Cambridge, MA</font><br><span style="color:rgb(153,153,153)"><a value="+16174957227" style="color:rgb(17,85,204)">(617) 495-7227</a></span></div></div></div>
</div></div>