MOC standard identifiers

[Pierre Fernique]

Hi all,

I would prefer to avoid to specify the MOC serialization detail returned 
by the data provider in the VO registry. Concretely, just to remove the 
"FITS" word in the VODataService 1.2 WD and let the HTTP content-type 
does the job as suggested by Markus (text/plain;content=MOC and 
application/fits;content=MOC)

=> "/when a footprint url in the registry has an ivoid attribute set to 
ivo://ivoa.net/std/moc, a MOC must come back./"

Regards
Pierre

Le 12/06/2019 à 17:32, Markus Demleitner a écrit :
> Dear Apps,
>
> The VODataService 1.2 WD says that when a footprint url in the
> registry has an ivoid attribute set to ivo://ivoa.net/std/moc,
> a FITS MOC must come back.
>
> While this is a bit of an abuse of footprint/@ivo-id (we'll have to
> work that out in Registry -- a cleaner alternative would be to
> introduce a standardID attribute, and if you have opinions on this,
> feel free to speak out), my current qualm with this is that it is
> conceivable that data providers may one day want to use other MOC
> representations on footprint endpoints, and then we'd have to hack
> around the broad statement "it's a MOC".
>
> What I'd prefer: MOC defines two standard keys, perhaps even
> versioned, as in
>
> * ivo://ivoa.net/std/moc#fits-1.0
> * ivo://ivoa.net/std/moc#ascii-1.1
>
> I believe the language to state this is minor enough to add it during
> MOC RFC, and I'm happy to edit the registry record so it reflects
> this.
>
> The one thing that again hurts me a bit with this is that what we're
> doing here is really already covered by the well-known IETF media
> types, and in a way it might be smart, too, to define that when ASCII
> MOCs are transmitted in a MIME context, they should be declared as
>
> text/plain;content=MOC,
>
> whereas FITS MOCs would be
>
> application/fits;content=MOC.
>
> If that were adopted, in VODataService we could keep the plain ivoid
> (which is already declared by a number of resources; but I'd say
> not so many that it's unreasonable to fix it) and warn implementors
> that any approved MOC serialisation can come back from them and they
> need to look at the media type (which clients have because footprint
> URLs always point to HTTP endpoints).
>
> Thoughts or advice, anyone?
>
>          -- Markus


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/apps/attachments/20190613/ba2b8e2a/attachment.html>