<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi all,<br>
<br>
</div>
<div class="moz-cite-prefix">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)<br>
<br>
</div>
<div class="moz-cite-prefix">=> "<i>when a footprint url in the
registry has an ivoid attribute set to ivo://ivoa.net/std/moc, a
MOC must come back.</i>"</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Regards<br>
Pierre<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Le 12/06/2019 à 17:32, Markus
Demleitner a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:20190612153252.pk7kwwfinj4ktwuo@victor">
<pre class="moz-quote-pre" wrap="">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
</pre>
</blockquote>
<p><br>
</p>
</body>
</html>