Various minor problems in VO-DML repo

[CresitelloDittmar, Mark]

Hi,

Sorry if I'm getting things jumbled here..
If I'm reading this thread right:
  o Markus is creating annotated VOTables
  o per the MIVOT spec, sees there is a 'url' element which he wants to
populate.
     ** perhaps mistakenly thinking it is required, or just being thorough.
  o what value to put there?
     MIVOT says it is the URL to the vodml/xml file.  He knows where those
are.
     So, minimally all he needs is to copy the URL from the IVOA Doc &
Standards
     page and use that in his annotation block.
        e.g: "https://www.ivoa.net/xml/VODML/Coords-v1.vo-dml.xml"
  o but.. being super thorough, he knows that the VODML spec says there is
     a MODEL node within the vodml/xml file which has a 'uri' element
specifying
     the value which should go in the annotation.
     - unfortunately, NONE of the vo-dml/xml files in the official
repository have
       a value in that field.  And, ironically, the ivoa model doesn't even
have the
       field, and does not validate.

So, while I don't see this as a major problem or indictment of our work to
date,
I do agree that:
   1) the ivoa model vo-dml/xml file in the repository should validate
   2) the other model vo-dml/xml files should have a valid value in the uri
field
       (though it's worth is questionable and can be discussed as a change
        to the VODML spec, this field really isn't intended to be empty).

   > So... who will fill in the uri-s?
   I'm on vacation next week, but can take on an action to provide copies
of the
   current vo-dml/xml files with the 'uri' element filled in.  Half of them
are mine anyway.

As for DaCHS:
  If you are storing local copies of the vo-dml/xml files, this field is
  the place to store 'where it came from'.  And for non-rec models,
  this is especially important since you can't guess.

  This workflow is an argument for the value of the vodml model.uri element
  being mandatory (and non-empty). To support these cases, and to support
  local extensions to models.. with vo-dml/xml files published outside the
ivoa repo.


Mark


On Thu, Feb 23, 2023 at 7:08 AM Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> wrote:

> Hi,
>
> On Thu, Feb 23, 2023 at 10:42:46AM +0100, Laurent Michel wrote:
> > > On 23 Feb 2023, at 08:45, Markus Demleitner <
> msdemlei at ari.uni-heidelberg.de> wrote:
> > > And lugging the old minor versions around does have a price tag.  For
> > > instance, these minor-versioned URIs may tempt people into putting
> > > these into MIVOT's MODEL/@url.   Whether or not that's bad is an
> > > interesting question (which perhaps also should be addressed in
> > > MIVOT).  If this were XML, it'd be a disaster.
> > >
> >
> > My point of view is that minor-versioned documents are related to
> > existing standards, therefore they must keep available on the doc
> > repo as long as the (old) standards exists.  Hiding the minored
> > versions is somehow like prohibiting using those version. Is that
> > what we want?
>
> Yes, I would argue that way.  Since minor versions are intended to be
> backwards compatible, I don't think there is a good reason to go back
> to older minor versions except for debugging-like tasks, and these
> are better served with proper version control where you have comments
> on why certain changes were being made.
>
> But I won't quarrel here -- this certainly is one of the lesser
> problems we currently have with our VO-DML repo, and we only need to
> agree on it when there's going to be a DM update anyway.
>
> > > local copies of those[1] and hence can't easily tell what URIs they
> > > may prefer.
> > for tne record:
> > The MIVOT schema requires MODEL at url not be empty IF PRESENT.
> > <MODEL name=“MyModel”/> is valid.
> >
> > I like the Paul's idea of encouraging the usage of short URLs e.g.
> > "MyModel.v1.vom-dml.xml” and letting clients getting them from
> > their favorite place (file:// or https://ivoa.net
> > <https://ivoa.net/>…) This must be clarified in the MODEL section
> > of MIVOT.
> >
> > Would this help DACHS for dealing with documents with empty uri?
>
> Well, if I don't have to put in the URIs, I'll just look the other
> way when there's empty URIs.  But it would certainly be wise to
> inquire again why exactly the uri element was made mandatory in
> VO-DML.  It sure feels... odd to decide to have a mandatory element
> that is in general empty, and we might block some important thing
> that the VO-DML authors had in mind.
>
> I can't resist: this is another example where just adding features
> without a solid implementational backing makes everyone scratch their
> heads later (and that's the best possible outcome).  Which is exactly
> why I think we should make MIVOT 1.0 a *whole* lot leaner.
>
> > > So, either the models give that themselves, or I have to provide a
> > > local mapping in DaCHS, the latter obviously being ugly and brittle.
> >
> > I do not follow you, if you need the document to get its URI,  you
> > must first have that URI to get the document.
>
> Sure.  But then I have checked it into DaCHS VCS, and by the time
> DaCHS reads it'll need to know where it originally came from (when I
> need to give MODEL/@uri, that is).  And that I can either take from
> the document or from a hand-maintained local mapping.
>
> But if I can safely leave out MODEL/@uri, that's a non-issue *for me*
> at this point.
>
> > AS Paul said, you can cross-check the document URI with its content
> > by using <name><version> elements.  No need of any <uri> element.
>
> ...except for VO-DML files not (yet) in the IVOA repo.  I suspect
> that's why people came up with the uri element in the first place.
> But at this point I think that's another of our lesser problems.
>
> > A CC-0 label on the top of the XML files would be nice.
> > Do you we need errata for this?
>
> Me, I don't think so.
>
>        -- Markus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20230223/0508418a/attachment.htm>