24_08_23

Development Roadmap (08/2023)

Astropy

We keep the pattern already implemented in lmichel/astropy:

• ModelMapping class added to tree.py
• An instance of that class is added to the Resource class
• This instance holds the XML mapping block as a string.
• It is set by the Resource parser.

This hodler clas can also write the XML string into a Votable instance.

Whatchout: This writing method must be hardened in order to prevent non-XML string injection in a VOTable.

Implementing the annotation R/W operations into Astropy allows any other package (affiliated or not) to work with MIVOT.

PyVO

Astropy is just enable to provide an XML string containing the annotations. This string must be processed at application level.

We propose to implement a stack of processing levels in PyVO. The architecture of this implementation could used in other packages or even other languages.

Below are the different proposed levels

1. Parsing the XML contained in the string returned
2. Resolver able to build a model XML instance by resolving references.
3. bis Resolver able to build a model XXX (see Gilles proposal based in the Py reflexion) instance by resolving references.
4. An iterator able to return a model view of the each data row.
5. A resolver able to build Python classes for the most popular models
6. A resolver able to build instances of Astropy classes from the annotations
7. A resolver able to build instances of extended Astropy classes from the annotations.