<div dir="ltr">HI Mark<br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 14, 2017 at 10:31 AM, CresitelloDittmar, Mark <span dir="ltr">&lt;<a href="mailto:mdittmar@cfa.harvard.edu" target="_blank">mdittmar@cfa.harvard.edu</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Gerard,<br><br><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 13, 2017 at 12:31 PM, Gerard Lemson <span dir="ltr">&lt;<a href="mailto:gerard.lemson@gmail.com" target="_blank">gerard.lemson@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">HI Omar<div>Agree with most of what you write, but would like to focus on this proposal:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Only <span><br><div>To recap:<br></div><div>  1. my personal Yay! to removing the ivoa model from the current VODML PR.<br></div><div></div></span></div></div></div></div></blockquote></div><br></div></div><div class="gmail_extra">I tried arguing that we need a base model with primitive types to be able to create models.</div><div class="gmail_extra">(Unless of course every model would define all their own basic primitive types, something I truly hope no one wants).</div></div></blockquote><div><br></div><div>I&#39;m sure we agree that a base model for primitives is needed.<br></div></div></div></div></div></blockquote><div><br></div><div>If there are objects to its use, I am not sure that there is agreement to its existence.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra">So if we only have a language but no basic types we have a problem.</div><div class="gmail_extra">Now IF you&#39;re proposing to still have ivoa model and vo-dml spec go through the process in synch there should be no problem, but if now ivoa model would be delayed, I&#39;d much rather keep it inside the spec.</div></div></blockquote><div><br></div>I think they could go in sync.  The argument for separating is more that the content may evolve and change (in the short term.. presumably would settle quickly to a static state since it will be so broadly used), without the need to modify the vo-dml standard.<br><br></div></div></div></div></blockquote><div>Note that the model was never &quot;only&quot; to be defined in the VO-DML spec document. There were always going to be separate VO-DML/XML and VO-DML/HTML documents. So now it seems that, after moving the description from an appendix to a normative section in the vo-dml spec (in reaction to RFC comments) it is proposed we remove that text completely? Do we need a separate document with that text, or might it be sufficient to keep only the VO-DML/XML and VO-DML/HTML? This model is so simple, that might suffice?</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"></div><div class="gmail_quote">For example..<br></div>   With the recent Coords re-work for the Cube/TimeSeries thread, in order to satisfy the user-end requirements, we need<br></div><div class="gmail_extra">   a &#39;anyType&#39; parent to the primitives in the ivoa model.  Perhaps you could consider this my formal request to add that<br></div><div class="gmail_extra">   since this seems like a much more user-friendly modeling  (the annotations are easier to work with from an application<br></div><div class="gmail_extra">   point of view).   Whether this is in V1.0, or V1.1, I&#39;m not particularly concerned, but it would need to go forward with the<br></div><div class="gmail_extra">   cube/coords work.<span class="gmail-HOEnZb"><font color="#888888"><br></font></span></div><span class="gmail-HOEnZb"><font color="#888888"><div class="gmail_extra"><br></div></font></span></div></div></blockquote><div><div>We had a similar issue in SimDM, where we did not know the property that a measurement value represented, and hence we could not predict the datatype. We did not introduce an anyType there for technical reasons, we actually wanted to work with the data model explicitly. </div></div><div><br></div><div>The &#39;ivoa&#39; model used to have a similar such type, namely AtomicValue. Had a UCD only, and was base class of a host of &quot;extended&quot; types, including the Quantity types which added a unit. We removed AtomicValue when we removed the ucd attribute as it seemed to become superfluous. </div><div><br></div><div><div>Note that the AtomicValue was never a super type of all the types, which I am assuming you want anyType to be the supertype of as many of the types as possible. Correct? Would it be sufficient to make anyType be a supertype of the primitive types only? </div><div>If we do so (and even if not) I think we should also change the definitions of rational and complex. ISO modelling these explicitly with numerator/denominator and imaginary/real attributes we&#39;d make them primitive types and leave the representation up to the serializer. So then also these types could be subtypes of  the primitive anyType, which as structured types they could not be.</div><div><br></div></div><div>If no one sees a problem with adding anyType as a super type to all primitive types, I see no reason to wait for a version 1.1.<br></div><div><br></div><div>Cheers</div><div><br></div><div>Gerard</div><div><br></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"><div dir="ltr"><div><span class="gmail-HOEnZb"><font color="#888888"><div class="gmail_extra"></div><div class="gmail_extra"><div class="gmail_quote"> <br></div>Mark<br></div></font></span></div></div></blockquote><div> </div><div><br></div></div></div></div>