Various minor problems in VO-DML repo

[Paul Harrison]

> On 22 Feb 2023, at 12:17, Markus Demleitner <msdemlei at ari.uni-heidelberg.de> wrote:
> 


I agree that there are some inconsistencies in the way that the VO-DML models are published that need to be cleaned up. I think that there is some unnecessary repeated information inside the files (see https://github.com/ivoa/vo-dml/issues/6) that was only there to make some of the documentation processing easier, but that this information is redundant as URLs for finding published VO-DML instances could be created with the simple rule that the url is created as

https://ivoa.net/xml/VODML/<name>-v<version>.vo-dml.xml

where bracketed terms refer to the contents of those elements in the model.

In addition we should have the usual rule that

https://ivoa.net/xml/VODML/<name>.vo-dml.xml 

redirects to the latest version.



> Dear DM,
> 
> I didn't look for them -- but while giving in to the fact that I'll
> have to shallow-parse the VO-DML in order to come up with the
> <mild expletive deleted> VO-DML ids in MIVOT I stepped into a few
> problems related to obtaining VO-DML files that, I think, nicely
> illustrate my point that whatever isn't validated (or at least used)
> by a machine is broken.
> 
> (1) The IVOA types DM (sigh!) ivoa.vo-dml.xml
> (https://ivoa.net/xml/VODML/IVOA-v1.vo-dml.xml) is schema-invalid:
> 
>  <string>:7:0:ERROR:SCHEMASV:SCHEMAV_ELEMENT_CONTENT: Element 'title': This element is not expected. Expected is one of ( identifier, uri ).
> 
> This is because the model element in VO-DML has a mandatory uri
> element, which is described as:
> 
>  Each model has an associated model URI that MUST be used to
>  reference it, for example in ModelImports or in VOTable
>  annotations. Dereferencing the model URI and following redirects
>  yields the latest VO-DML for the data model
> 
> Inserting <uri>http://www.ivoa.net/xml/VODML/v1</uri> in front of the
> title element fixes this.

I think that uri element should be dropped (or at least to comply with our schema versioning rules, made optional) - it is only repeating information that can be worked out from other elements.
> 
> (2) While I was figuring this out, I noticed that in coords, meas,
> and phot (didn't check the others), the uri element is present but
> empty.  I'm pretty sure we should fix that, and I guess as an
> editorial oversight I'd even do it without an erratum process.
> Who'll push it along?

I would recommend removing as above.
> 
> [but at least these other vo-dmls are schema-valid]
> 
> (3) Requesting the coords model at
> 
> https://ivoa.net/xml/VODML/Coords-v1.vo-dml.xml
> 
> results in a 300 Multiple Choices response from our web server.
> That's because the underlying file is called Coords-v1.0.vo-dml.xml
> (note the extra ".0").  I think I've always argued that -v1 should
> redirect to -v1.0.  But I'm open to any alternative, as long as
> people get a plain 200 or redirect when they access the DM URI.
> Who'll tackle this?
> 
Clearly there is an inconsistency in the forwarding - but again I would recommend a strict rule above, which would mean that the URL is not case consistent (the <name> of the model is “coords”). This case inconsistency is true of nearly all of the published models (including the base IVOA one).

In addition to the above rules, I have updated the standard VO-DML processing (at https://github.com/ivoa/vo-dml) not to use absolute URLs for imports (https://github.com/ivoa/vo-dml/issues/3) as it is the much easier to do local processing if that is what is desired, or a mixture of local and published via XML catalogues. This also means that the <url> sub element of the <import> should be removed from instances to avoid confusion as it is no longer used.

Regards,
	Paul.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2893 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20230222/9707138f/attachment.p7s>