DM Workshop wrap-up

[Mark Taylor]

François,

Yes, I think that use of the xs:any type is the right way to go here.

However, that is already accommodated by the VOTable schema as it stands.
Quoting from https://www.ivoa.net/xml/VOTable/VOTable-1.4.xsd:

  <xs:complexType name="Resource">
    ...
      <!-- Suggested Doug Tody, to include new RESOURCE types -->
      <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
    ...
  </xs:complexType>

which means that the elements from the VODML schema can be included
within a RESOURCE element in a VOTable document, with no changes
to the VOTable standard required at all (thanks to Markus for
pointing this out).
So something like this should work out of the box:

  <VOTABLE version="1.4"
           xmlns="http://www.ivoa.net/xml/VOTable/v1.3"
           xmlns:dm="http://www.ivoa.net/xml/vodml">
    <RESOURCE type="meta">
      <dm:VODML ...>
        <MODELS>
        </MODELS>
        ...
      </dm:VODML>
    </RESOURCE>
    <RESOURCE type="results">
      <TABLE>
        ...
      </TABLE>
    </RESOURCE>
  </VOTABLE>

A VOTable document like that validates for me under the VOTable 1.4
schema (e.g. xmllint -noout -schema VOTable1.4.xsd).  At present votlint
(http://www.starlink.ac.uk/stilts/sun256/votlint.html) does complain:

   WARNING: Element in wrong namespace (http://www.ivoa.net/xml/vodml not http://www.ivoa.net/xml/VOTable/v1.3)

but that's really a votlint bug that I will fix.

I would certainly favour this approach rather than adding new VOTable
elements, to avoid unnecessary coupling between the VODML and VOTable
standards.

Concerning the xsi:type="mapping:VODML-type" attribute:
as I understand it, that wouldn't work with a schema in the form
of the one at

   https://github.com/ivoa-std/ModelInstanceInVot/blob/master/schema/xsd/merged-syntax.xsd

since that defines elements directly and not types (Gerard queried
this stylistic decision during the DM workshop session #4).

So I'm not quite sure how validation of the embedded VODML would
proceed: either the schema could be rephrased to define types, or
perhaps XSD validators are able to determine the required contents
based on the <VODML> element name without requiring an xsi:type.

One other point on the current merged-syntax.xsd: use of XMLSchema 1.1,
instead of 1.0, makes it harder to validate using some tools.
Java support at least is not so good for XSD 1.1, so I don't know
whether votlint would be able to provide XSD validation for VODML
if it was defined using this schema.

Mark



On Fri, 16 Jul 2021, BONNAREL FRANCOIS wrote:

> Hi all,
>     Considering the VOTAble schema versioning issue, with the "import" of a
> mapping syntax which may evoluate on its own I wonder i something like the
> following could work.
>     1 ) in next VOTABLE schema version, create a "VODML" tag inside VOTable of
> type "anyType" (minoccurs = 0 of course)
>     2 ) in VOTABLE documents type this VODML tag with an
> xsi:type="mapping:VODML-type" , with "mapping" xmlns defined as the last
> version of the mapping xml schema (can be done with attributes of the VODML
> tag)
>     3 ) as far as I remember this would make the two schemata independant and
> does not require that VOTABLE documents import the mapping schema
> 
> Do you think it could work ?
> 
> Cheers
> François
> 
> Le 15/07/2021 à 11:36, Laurent Michel a écrit :
> > Dear DM,
> > 
> > Last Tuesday we had our last DM workshop meeting.
> > This concluded a fruitful 7-month process whose main conclusions and
> > prospects are listed below.
> > 
> > An overview of the work done has been presented by LM
> > (https://wiki.ivoa.net/internal/IVOA/Dm2021/MAY2021-ws41.pdf
> > <https://wiki.ivoa.net/internal/IVOA/Dm2021/MAY2021-ws41.pdf>)
> > 
> > Conclusions in short
> > ================
> > 
> > • Models:
> > • Meas, Coord, PhotDM, Dataset, Cube and MANGO accepted
> > • New use-cases to be investigated
> > • X-RAY Astronomy
> > • Asteroids, multi-core datasets
> > • CTA and MM astronomy : meta-data characterization
> > 
> > • Data Provider / client specific use-cases
> > • Need for annotations to help processing spectra
> > • Need to associate parameters
> > • Need for a simple description of the photometric calibration
> > • Need for a simple view on Provenance
> > • Annotation on the fly feasible
> > • Model-based PyVO API easy to design
> > 
> > • Mapping syntax
> > • Divergence between the 2 proposals (VODML mapping and ModelInstanceInVot)
> > • Proof of concept for a YAML serialization of model instances
> > 
> > Annotation
> > =========
> > An important effort has been made over the last 6 weeks to merge the 2
> > syntax proposals:
> > • see on https://github.com/ivoa-std/ModelInstanceInVot
> > <https://github.com/ivoa-std/ModelInstanceInVot>
> > 
> > • 3 items available so far:
> 
> 
> 

--
Mark Taylor  Astronomical Programmer  Physics, Bristol University, UK
m.b.taylor at bristol.ac.uk          http://www.star.bristol.ac.uk/~mbt/