<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix"><br>
Dear App members,<br>
<br>
The study of the 3 VODML Gerard's proposals leads me to raise
these 3 points, and a suggestion.<br>
<br>
For App WG point of view, first of all, we have to assure that
this DM effort <b>(1) keeps the VOTable backward compatibility.</b>
And in a second point, I would like that<b> (2) the VOTable
standard keeps a relative simpleness</b>. Otherwise, it will
become more and more difficult to sell it to data producers. So <b><font
color="#006600">VODML must stay as simple as possible and
optional</font></b><b> </b>otherwise the real result will be
the emergence of new basic formats (JSON, ASCII, FITS or whatever)
with poorer or divergente metadata description than a basic
VOTable without VODML (cf. coordinate STC note usage). And in
third point, I would like to (3) <b>keep VOTable standard
manageable</b>. I'm not sure that we have time and energy for
re-opening a full VO discussion each time we need to adjust VODML
XML element/attribut (VODML, TYPE, ROLE, ALTTYPE, ...). <br>
<br>
My idea would be to <b>suggest</b><b> the addition of just one
optional new element <VODML></b> in GROUP, PARAM,
FIELDref, PARAMref (and why not GROUPref), but for which, its XML
definition (sub-types, attributs...) would be described not in
VOTable document itself but in a separated IVOA standard managed
by the DM group (through the classical IVOA standardization
process - may be directly insert in the VODML standard itself). By
this way the DM effort could follow is own way and time with a
relative freedom.<br>
<br>
Best regards,<br>
Pierre<br>
<br>
<br>
<br>
Le 11/02/2015 17:02, Gerard Lemson a écrit :<br>
</div>
<blockquote
cite="mid:CAPoLd+whx9_nxaApYRixCvV-G91t3JWYWrgF6xoFOAoE5-cWBQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>Dear all</div>
<div>It would be nice if we could quickly agree how to annotate
VOTable elements with metadata pointing to VO-DMl data models.</div>
<div>In the votable/vo-dml session in Banff we came to a
decision to add a new element to VOTable that would represent
this mapping and would take the place of the utype attributes
we had assumed to use for that in the current mapping document
in <a moz-do-not-send="true"
href="https://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/MappingDMtoVOTable-v1.0.docx">https://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/MappingDMtoVOTable-v1.0.docx</a>.</div>
<div>The detailed design of this element was still left open and
I sent out an email shortly after the interop in which I made
some suggestions, which I thought I had adequately illustrated
with examples of the possible XML schema snippets. Maybe this
was not clear, so I have updated the contents of</div>
<div><a moz-do-not-send="true"
href="https://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/samples/votable">https://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/samples/votable</a></div>
<div>It now contains for three possible designs, labeled 4a, 4b
and 4c, full VOTable schemas and three corresponding versions
of a VOTable following these schemas and showing the different
ways to annotate the same tables.</div>
<div><br>
</div>
<div>E.g. <a moz-do-not-send="true"
href="https://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/samples/votable/VOTable-1.3_vodml4a.xsd">https://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/samples/votable/VOTable-1.3_vodml4a.xsd</a>
</div>
<div>is a possible new schema and </div>
<div><a moz-do-not-send="true"
href="https://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/samples/votable/VOTable_Prop4a.xml">https://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/samples/votable/VOTable_Prop4a.xml</a></div>
<div>an annotated VOTable following that design.</div>
<div><br>
</div>
<div>Note that in the three different proposals only the
*content* of the <VODML> elements, as described by the
structure of the VODMLAnnotaiton complexType definition, is
different. Their association to PARAM, GROUP, PARAMref and
FIELDref elements is the same.</div>
<div><br>
</div>
<div>Please let me know if this is still not clear or comment on
the design possibilities.</div>
<div><br>
</div>
<div>Cheers</div>
<div>Gerard</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Oct 15, 2014 at 5:47 PM, Gerard
Lemson <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:gerard.lemson@gmail.com" target="_blank">gerard.lemson@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Dear all<br>
<br>
During the VO-DML-in-VOTable discussion at the last interop
we decided to go<br>
with (something like) proposal 4 on the wiki at<br>
<a moz-do-not-send="true"
href="https://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/samples/votab%0Ale/VOTable_Prop4.xml"
target="_blank">https://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/samples/votab<br>
le/VOTable_Prop4.xml</a> Other options can be found in
the same folder.<br>
What we now need is to finalize the design for the XML
tag(s) to add to<br>
VOTable.<br>
I have created a mockup of an XML schema with a complexType
definition<br>
reflecting the new element.<br>
The design used in proposal 4 above is represented by
proposal 4a in the<br>
schema. It has attributes for role and actual type, and
elements for<br>
alternative types. Proposals 4b and 4c vary on this theme.
All use a<br>
simpleType definition reflecting the
model-prefix+':'+vodml-id pattern used<br>
to refer to VO-DML elements. See the mapping document for
more detailed<br>
descriptions (taking into account the fact that that
document will have to<br>
be updated with the choice to be made here).<br>
<br>
Note, I am not making statements on whether these two types
must be in the<br>
VOTable targetnamespace. Andreas had some thoughts on this
that I hope he<br>
will send to the list in reply.<br>
<br>
And obviously the final design may differ from these
proposals if necessary,<br>
but let's please converge on an acceptable design soon so
Omar and I can<br>
update the mapping document.<br>
<br>
Cheers<br>
<span class="HOEnZb"><font color="#888888">Gerard<br>
<br>
</font></span></blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>