Adding a section about MIVOT and the registry

[lmichel]

The current document specifies the mapping syntax.
Although being out of the document scope, the way to declare in the registry the capability for a resource to serve annotated VOTable should be sketch-up in the document

[lmichel]

Proposal to set in a specific appendix:

Appendix B : Mivot and the registry

MIVOT adds a new feature to the VOTable format which allows a new way to consume data. The standard was designed so that this new functionality could be ignored by regular clients, as services are not required to provide annotated data anyway. This flexibility requires a standard way to declare the availability of annotated data. The registration of this capability must be applicable to any service running any protocol that possibly serves data as VOTables.

In this context it is important to inform clients in advance that a service can deliver annotated data.
We identified 2 ways to do this:

• Defining a specific mime-type extension allowing clients to tell the server that annotated responses are accepted if available. This has been exercised on the Xtapdb (https://xcatdb.unistra.fr/xtapdb/) service which understands the application/mango mime type as a request for mapping the query results on the Mango DM. The limitation if this approach is that one mime-type has to be defined per model or if we do not want to specify any specific model, e.g. mime-type:application/mivot` clients will have to parse the VOTable to discover which models are mapped.
• The other option is to define a new registry (ref??) capability that would list the mapped model and that could be appended to the resource capabilities. The definition of that capability is out of the scope of this standard which is focused on the syntax.

It is to be noted that these 2 options can be mixed together.

[lmichel]

answered in #184