Design Options

2 Design options

• Option one: less work but might skip interesting features provided by annotated data
• Option two: more work but more interesting features

Global pattern

The adopted guideline is implement the model related code in PyVI as much as possible. There are 2 reasons for this:

• The Astropy code is not VO code. Astropy user must not be forced to deal with VO features (class, functions)
• The PyVO development cycle is more flexible due to community whcich is both smallerr and VO aware.

The only things we have to put in Astropy are the read/write operations of the MIVOT block. The reason is that the MIVOT block must be extracted on the fly during the parsing. Doing this in PyVO would require to extend the Astropy VOTable parser into a PyVO class with a great danger of divergences due to software evolution.

All others model-related operation are implemented in PyVO.

All model activities are under the control of a MIVOT parser (namely the ModelViewer) From the user perspective, it is in charge of:

• Providing access to XML components of the mapping
• Building VO Model Mock instances
• Building Astropy Quantities directly from the mapping This module must be hosted by PyVO. It will be the entry point of the VOModel API.

Funtionality	AStropy	PyVO
Mapping block Read/Write	X
Mapping block parser		X
Model extension for Quantities		X
VO Model classes		X