<div dir="ltr"><div class="gmail_extra"><br></div><div class="gmail_extra">Hi Markus,<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 23, 2017 at 4:46 AM, Markus Demleitner <span dir="ltr">&lt;<a target="_blank" href="mailto:msdemlei@ari.uni-heidelberg.de">msdemlei@ari.uni-heidelberg.de</a>&gt;</span> wrote:<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div class="gmail-a3s gmail-aXjCH gmail-m15a6a5dfcf37cc90" id="gmail-:1ib">Now, my appeal is to have the same property across DMs: We should<br>
build things so that a document can be valid NDCube-1.0 regardless of<br>
whether it uses Dataset-1.0 or Dataset-2.4 or both, or even none<br>
of them.  The point of my previous mail was that that&#39;s feasible; </div></blockquote></div><br></div><div class="gmail_extra">The problem with this is that it would depend on how *exactly* the importing model imports and uses the imported model.<br><br></div><div class="gmail_extra">If a TimeSeries *is* a Dataset (the example is arbitrary), then it is important to know what version of a Dataset it is, because Dataset-1.0 and Dataset-2.0 may be, by design, not compatible. Your point is still relevant for minor increments, though. Depending on the type of parser, it might not really matter if a TimeSeries is expressed in terms of Dataset-1.0 or Dataset-1.2, because by design a Dataset-1.2 valid annotation is also a valid Dataset-1.0 annotation, and vice versa. A validator would still be able to validate the instance, for example.<br><br></div><div class="gmail_extra">In any case an importing VODML model MUST say what models it is importing, otherwise it cannot refer to their elements, not even to state that &quot;something&quot; has &quot;such and such&quot; datatype, e.g. that a ts:TimeSeries is a special kind of ds:Dataset: &quot;such and such&quot; would require a vodml reference, i.e. the prefix identifying a major version of a model (ds) plus the ID of the data model element (Dataset).<br><br></div><div class="gmail_extra">Now, the designers of the importing model can be wise and reduce the number of references to an imported model if the coupling between the models is inherently loose. This might involve using object composition over type inheritance, if this makes sense from a modeling point of view. Still, if they want to enable compatibility with a new major version of a model, they need to create a new xml descriptor that describes the relationship with the new model. It could be trivial to do so, but this depends on the inherent relationship between the models and how they were designed. Could this be done bumping only the minor version of the importing model? I have to say I don&#39;t know, we never thought about this.<br><br>Most likely, if we wanted to enable this (new) requirement we would need to make some tweaks to the VODML spec, and possibly to the mapping spec. One might say that TimeSeriesDM imports the Dataset type from any version of DatasetDM, and the binding is done at serialization time, i.e. when a provider materializes an instance of a TimeSeries. Some mechanism must allow clients (e.g. validators) to know what versions are being bound together. Again, this was not an explicit requirement, so no thought went into it.<br><br>However, I could see a model (probably not DatasetDM) removing a type between major increments, possibly leaving importing models with dangling references to non-existent types, e.g. ad absurdum DatasetDM-2.0 might remove the Dataset type altogether, so TimeSeries would be left with a dangling reference to a Dataset type that does not exist anymore.<br><br></div><div class="gmail_extra">The only way I can see this working at this point is by removing the link altogether. It could be that TimeSeries is just an additional layer of metadata that can be added to a file on top of the existing ones. So something might be annotated as being both a Dataset (of any version) and a TimeSeries (of any version), hopefully with minimal overlap. Whether this makes sense, or it&#39;s convenient, depends on the models.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">None of the above means you cannot annotate a file with two different (major) versions of a model. You still can.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Hope this helps,<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Omar.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">P.S. I still owe you a couple of replies about models registration, I&#39;ll do it asap.<br clear="all"></div><div class="gmail_extra"><br>-- <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 style="color:rgb(17,85,204)" value="+16174957227">(617) 495-7227</a></span></div></div></div>
</div></div>