<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jan 17, 2019 at 5:12 AM Markus Demleitner <<a href="mailto:msdemlei@ari.uni-heidelberg.de">msdemlei@ari.uni-heidelberg.de</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
(a) Why do you keep the information that epoch's values are in DALI's<br>
ISO format in two places (COLUMN/@type and FIELD/@xtype)?<br>
<br>
(b) And even if you have a good reason to have the same piece of<br>
information in two places, why do you use two different vocabularies<br>
(ISOTime vs. timestamp)?<br>
<br>
I'd be great if I didn't have to answer them.<br></blockquote><div><br></div><div>That's a very good point. The thing is that the conversation on using the DALI types came about after we had proposed 3 different mapping strategies (the first one, six years ago, used VOTABLE 1.3, the second one added very few element types to VOTABLE 1.3, the third introduced a bunch of new element types).</div><div><br></div><div>I remember Pat giving a presentation on this at one of the latest Interops, and we probably never followed up. Maybe we should branch off and keep that conversation going. In my opinion the question is: can we find a formal way of reusing the DALI types in the VODML serialization and/or in the model definitions? Having VODML Mapping depend on DALI does not sound too wise, but it doesn't mean we can't do it or find a way around it.</div><div><br></div><div>Note that one of the design decisions of the first mapping proposals was exactly what Markus said, i.e. make sure existing parsers would be able to just keep parsing what they know, and just add DM/semanting information using additional markup. Those proposals were shot down. Then when redesigning Mapping we decided we didn't want to reuse the FIELD/PARAM type exactly to avoid the current type-attribute-creep (type, datatype, utype, xtype, to which people were suggesting adding a dmtype). There were also other reasons, i.e. trying to decouple the VODML element type from VOTABLE as much as possible.</div><div><br></div><div>Can we find a sustainable way to reuse the DALI types in DM in a rigorous, sustainable way that also facilitates things for parsers? I hope we can, or we should have rather compelling reasons not to.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Ah... well, I had in mind something a bit more concrete; you see, in<br>
DM I think we're doing us a favour if each box in our UML diagrams<br>
can be clearly and as unambiguously as possible (applying Occam's<br>
razor) derived from a requirement, which again would be derived from<br>
a very concrete use case ("merge two time series from different<br>
sources; examples of time series we want to look at include ivo://X,<br>
ivo://Y, and ivo://Z"). That way, I think a lot of the DM<br>
discussions would become a lot less tedious.<br>
<br>
</blockquote></div><div><br></div>Hear hear! I have been bringing this up so many times, for some reason everybody agrees but then we never do it. I wouldn't stop trying though.<div><br></div><div>Omar.<br clear="all"><div><br></div>-- <br><div dir="ltr" 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>