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

[Laurino, Omar]

Hi,

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

Omar.

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.


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


-- 
Omar Laurino
Smithsonian Astrophysical Observatory
Harvard-Smithsonian Center for Astrophysics
100 Acorn Park Dr. R-377 MS-81
02140 Cambridge, MA
(617) 495-7227
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/apps/attachments/20150312/d1e3e151/attachment.html>