Datalink feedback, the last: Misc

[Patrick Dowler]

Umm, ok I just commented on this in the message about the capabilities 
example...

In DALI (from TAP) we list short-form "aliases" for types and using them 
would be less prone to wierdness, but with less cient control of what 
happens. IIRC, the use case for specifying a mimetype directly was that 
if you wanted the votable to be rendered by a web browser, you needed in 
many cases to request text/xml and not leave it up to the service... but 
if you wanted to be able to configure the browser to send a VOTable to 
topcat (eg) you could do that by requesting application/x-votable+xml 
instead. It comes down to client control so a service can be used by 
various apps.

So, looks like services need mimetype parsers. It still seems better 
than making up our own names for everything.


On 17/04/14 01:12 AM, Markus Demleitner wrote:
> Here, again, the issue of content-type syntax comes up -- services
> must accept
>
>    application/x-votable+xml; content=datalink
>
> (with the blank) as well lest we shut out MIME types generated by
> perfectly standards-compliant libraries.  Not sure whether this needs
> to be stressed here -- and frankly, handling all crazy corner cases
> that result from MIME parameters fed in by implementations is tricky:
> May I reject
>
>    ...; content=datalink; encoding=utf-8
>
> although what I'm returning actually is utf-8 encoded datalink?  Full
> disclosure: my implementation currently completely gets this wrong.
>
> One of the larger issues I'm having with this is that there's no way to
> discover what RESPONSEFORMAT values a service supports.  On the
> capabilities endpoint, the parameters come in VODataService vs:param
> elements, and these do not allow the specification of valid values,
> and no other mechanism is defined right now

Yes, that seems to be the case. The VOTable service description of the 
service can describe the allowed values, but it doesn't currently say 
everything either (VODataService param can say use="required" which is 
not included in the VOTable way of describing a service).


On the bright side, we have (in DataLink meta resources) replaced the 
old PARAM name="INPUT:something" with a more general purpose construct 
embedded in VOTable so I think that is progress rather than just 
duplication. Having implemented the client and server side of that, it 
serves the intended purpose well.



-- 

Patrick Dowler
Canadian Astronomy Data Centre
National Research Council Canada
5071 West Saanich Road
Victoria, BC V9E 2E7

250-363-0044 (office) 250-363-0045 (fax)