<div dir="ltr"><div>Hi,</div><div><br></div><div>Sorry if I'm getting things jumbled here..</div><div>If I'm reading this thread right:</div><div> o Markus is creating annotated VOTables</div><div> o per the MIVOT spec, sees there is a 'url' element which he wants to populate.</div><div> ** perhaps mistakenly thinking it is required, or just being thorough.</div><div> o what value to put there?</div><div> MIVOT says it is the URL to the vodml/xml file. He knows where those are.</div><div> So, minimally all he needs is to copy the URL from the IVOA Doc & Standards</div><div> page and use that in his annotation block. <span class="gmail-Apple-converted-space"> </span></div><div> e.g: "<a href="https://www.ivoa.net/xml/VODML/Coords-v1.vo-dml.xml">https://www.ivoa.net/xml/VODML/Coords-v1.vo-dml.xml</a>"</div><div> o but.. being super thorough, he knows that the VODML spec says there is </div><div> a MODEL node within the vodml/xml file which has a 'uri' element specifying </div><div> the value which should go in the annotation.</div><div> - unfortunately, NONE of the vo-dml/xml files in the official repository have</div><div> a value in that field. And, ironically, the ivoa model doesn't even have the </div><div> field, and does not validate.</div><div><br></div><div>So, while I don't see this as a major problem or indictment of our work to date,</div><div>I do agree that:</div><div> 1) the ivoa model vo-dml/xml file in the repository should validate</div><div> 2) the other model vo-dml/xml files should have a valid value in the uri field</div><div> (though it's worth is questionable and can be discussed as a change</div><div> to the VODML spec, this field really isn't intended to be empty).</div><div> </div><div> > So... who will fill in the uri-s?<br></div><div> I'm on vacation next week, but can take on an action to provide copies of the</div><div> current vo-dml/xml files with the 'uri' element filled in. Half of them are mine anyway.</div><div><br></div><div>As for DaCHS:</div><div> If you are storing local copies of the vo-dml/xml files, this field is </div><div> the place to store 'where it came from'. And for non-rec models,</div><div> this is especially important since you can't guess.</div><div> </div><div> This workflow is an argument for the value of the vodml model.uri element</div><div> being mandatory (and non-empty). To support these cases, and to support</div><div> local extensions to models.. with vo-dml/xml files published outside the ivoa repo.</div><div><br></div><div><br></div><div>Mark</div><div><br></div><div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 23, 2023 at 7:08 AM Markus Demleitner <<a href="mailto:msdemlei@ari.uni-heidelberg.de">msdemlei@ari.uni-heidelberg.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
On Thu, Feb 23, 2023 at 10:42:46AM +0100, Laurent Michel wrote:<br>
> > On 23 Feb 2023, at 08:45, Markus Demleitner <<a href="mailto:msdemlei@ari.uni-heidelberg.de" target="_blank">msdemlei@ari.uni-heidelberg.de</a>> wrote:<br>
> > And lugging the old minor versions around does have a price tag. For<br>
> > instance, these minor-versioned URIs may tempt people into putting<br>
> > these into MIVOT's MODEL/@url. Whether or not that's bad is an<br>
> > interesting question (which perhaps also should be addressed in<br>
> > MIVOT). If this were XML, it'd be a disaster.<br>
> ><br>
><br>
> My point of view is that minor-versioned documents are related to<br>
> existing standards, therefore they must keep available on the doc<br>
> repo as long as the (old) standards exists. Hiding the minored<br>
> versions is somehow like prohibiting using those version. Is that<br>
> what we want?<br>
<br>
Yes, I would argue that way. Since minor versions are intended to be<br>
backwards compatible, I don't think there is a good reason to go back<br>
to older minor versions except for debugging-like tasks, and these<br>
are better served with proper version control where you have comments<br>
on why certain changes were being made.<br>
<br>
But I won't quarrel here -- this certainly is one of the lesser<br>
problems we currently have with our VO-DML repo, and we only need to<br>
agree on it when there's going to be a DM update anyway.<br>
<br>
> > local copies of those[1] and hence can't easily tell what URIs they<br>
> > may prefer.<br>
> for tne record:<br>
> The MIVOT schema requires MODEL@url not be empty IF PRESENT.<br>
> <MODEL name=“MyModel”/> is valid.<br>
><br>
> I like the Paul's idea of encouraging the usage of short URLs e.g.<br>
> "MyModel.v1.vom-dml.xml” and letting clients getting them from<br>
> their favorite place (file:// or <a href="https://ivoa.net" rel="noreferrer" target="_blank">https://ivoa.net</a><br>
> <<a href="https://ivoa.net/" rel="noreferrer" target="_blank">https://ivoa.net/</a>>…) This must be clarified in the MODEL section<br>
> of MIVOT.<br>
><br>
> Would this help DACHS for dealing with documents with empty uri?<br>
<br>
Well, if I don't have to put in the URIs, I'll just look the other<br>
way when there's empty URIs. But it would certainly be wise to<br>
inquire again why exactly the uri element was made mandatory in<br>
VO-DML. It sure feels... odd to decide to have a mandatory element<br>
that is in general empty, and we might block some important thing<br>
that the VO-DML authors had in mind.<br>
<br>
I can't resist: this is another example where just adding features<br>
without a solid implementational backing makes everyone scratch their<br>
heads later (and that's the best possible outcome). Which is exactly<br>
why I think we should make MIVOT 1.0 a *whole* lot leaner.<br>
<br>
> > So, either the models give that themselves, or I have to provide a<br>
> > local mapping in DaCHS, the latter obviously being ugly and brittle.<br>
><br>
> I do not follow you, if you need the document to get its URI, you<br>
> must first have that URI to get the document.<br>
<br>
Sure. But then I have checked it into DaCHS VCS, and by the time<br>
DaCHS reads it'll need to know where it originally came from (when I<br>
need to give MODEL/@uri, that is). And that I can either take from<br>
the document or from a hand-maintained local mapping.<br>
<br>
But if I can safely leave out MODEL/@uri, that's a non-issue *for me*<br>
at this point.<br>
<br>
> AS Paul said, you can cross-check the document URI with its content<br>
> by using <name><version> elements. No need of any <uri> element.<br>
<br>
...except for VO-DML files not (yet) in the IVOA repo. I suspect<br>
that's why people came up with the uri element in the first place.<br>
But at this point I think that's another of our lesser problems.<br>
<br>
> A CC-0 label on the top of the XML files would be nice.<br>
> Do you we need errata for this?<br>
<br>
Me, I don't think so.<br>
<br>
-- Markus<br>
</blockquote></div>