Datalink feedback, the last: Misc

[Markus Demleitner]

Dear DAL,

Wrapping up my gripes with Datalink WD-20140228, here are three
fairly minor points in one go:


(1) Simplify RESPONSEFORMAT
===========================

I'm still all for deleting 3.3.2, which says something about the
optional text output of datalink services.  I have to say I'm
skeptical on optional features in general, and that particular (text
output) causes quite a bit of prose while not touching the central
problem with text output: How to do service descriptions.  It's
unclear to me why anyone might want to have text output at all -- if
you do, please speak up now.  Json would be a different matter, ok,
but plain text?

If 3.3.2 goes, there's a paragraph in 3.4 that needs to go, too.

Now, I'm not entirely sure if RESPONSEFORMAT has a good place in
Datalink anyway (as the datalink response is pretty tied to VOTable
right now), but if it needs to be in there, I think we should
streamline 2.1.2 to

  The RESPONSEFORMAT parameter is described in DALI [1]; support for
  RESPONSEFORMAT is mandatory. If the parameter is not present in a
  request, its value defaults to
  application/x-votable+xml;content=datalink.  This is also the only
  value a service MUST support.

  Service implementers may support additional output formats but must
  follow the DALI [1] specification if they choose any formats described
  there.

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 (unless possibly
MAXREC=0, but that's not even mentioned in the current draft, and I
have a feeling we shouldn't do so -- datalink simply isn't just the
other DAL protocol).


In short: I don't see an easy way to make RESPONSEFORMAT remotely
useful in Datalink, and it's tough to define interoperable and stable
semantics for it.  This is why I'm personally voting for striking it
altogether. If we did this, the obnoxious "VOTable only" clause in
the first paragraph of section 4 can go as well.


(2) More comprehensive capability example
=========================================

I suggest at least filling out some minimal interface metadata in the
example for capability (and maybe rather keep the VOSI ones sketchy).
This could look like this:


<capability standardID="ivo://ivoa.net/std/DataLink/v1.0">
  <interface xsi:type="vs:ParamHTTP">
    <accessURL use="base">http://localhost:8080/data/test/foo/dlmeta</accessURL>
    <queryType>GET</queryType>
    <resultType>application/x-votable+xml;content=datalink</resultType>
    <param std="true">
      <name>ID</name>
      <description>The pubisher DID of the dataset of interest</description>
      <ucd>meta.id;meta.main</ucd>
      <dataType>string</dataType>
    </param>
    <param std="true">
      <name>RESPONSEFORMAT</name>
      <description>Format of the request document</description>
      <ucd>meta.code.mime</ucd>
      <dataType>string</dataType>
    </param>
    <param std="true">
      <name>REQUEST</name>
      <description>Request type (must be getLinks)</description>
      <ucd>meta.code</ucd>
      <dataType>string</dataType>
    </param>
  </interface>
</capability>


(with REQUEST and RESPONSEFORMAT going away if I had my way).


(3) GROUP name input
====================

I don't particularly like the GROUP name "input" in the service
descriptions -- what's in the group isn't input, it's metadata on
input, and my experience is that the safest way no avoid name clashes
is to call things what they are.  So, I'd like to repeat my proposal
to call the group inputParams.  Or something similar.  No big deal
though, just intellectual cleanliness.


Cheers,

            Markus