DataLink and reference to services

[Markus Demleitner]

Merry Christmas all around,

Before replying to François' more content-centric points below, let
me briefly comment on whether we need a separate "data access"
standard on top of datalink.

First, I don't really care if we have one or two docs.  I do care
however, that we have something out quickly that tells people: Well,
this is how you do cutouts.  If it can do most everything else of
this type, too, great.

I claim the fastest way to do that is include the proposal basically
based on SSA getData in Datalink; it's not terribly much text, it's
more or less proven for related use cases, it exists (with some work
left to do).  Also note that the standards process alone incurs a
certain amount of overhead, so having less of that sounds like a good
idea to me.

On the other hand, when is it better to split up standards?  Good
reasons, I think, is if they're so decoupled that they can be
developed independently of each other, that the material is so
volumunious that exposition greatly benefits from a somewhat more
artificial modularization, or that we can quickly gain consensus on
one issue, while another is more contentious *and* the consensus is
already useful without the contentious parts.

I do not think any of these cases applies here; at least if you grant
that in-datalink service description is an important use case,
almost everything original to "accessData" is needed for datalink
already, so the two are strongly coupled.

And no, I do not think "there's an IVOA standard for it" is a
necessary or required condition for "it's important" :-)

Having said that, on to Francois' concrete points:

On Thu, Dec 19, 2013 at 11:44:01AM +0100, François Bonnarel wrote:
>      *   A dataset designated by its PublisherDID , or by a
>        known-in-a-given-context ID can be discovered in several ways.
[...]
>          So DataLink, a protocol designed to associate various ressources
>    to Datasets has to be defined independantly from any DAL protocol in
>    order to be used in a flexible manner. This doesn't mean that DataLink

Well, Datalink is a protocol belonging to DAL, and the way things are
written now, it's even a first-class DALI service.  But true, it
shouldn't be coupled to any specific protocol.  

Saying how to define data access services and some recommended ways
to express certain physics doesn't do that coupling, though, and even
in my little draft there's material "belonging", as it were, to
Obscore/SIAv2 as well as SSAP.

>      * The DataLink service or functionality response bounds datasets to
>        resources which may be  services. Either IVOA services or free
>        services. It is important to list all these links together in an

Just as an aside: During my implementation I thought hard how I could
usefully provide links to IVOA standard services, but I didn't come
up with any.  I'd be grateful for insight on what the use cases here
are.

>        homogeneous way without REQUIREMENT to describe the linked services
>        themselves at the same time (just because these services should be
>        described elsewhere (registry) or autodescribed (see below).

-1 for requiring registry access for service operation.  This kind of
thing hasn't worked so far, there's not reason to assume it's going
to work in the future.  I may wish it would, and certainly having
information about supported parameters is useful for service
discovery (but then I don't believe datalink service discovery has
many use cases), but that's different from service operation.
Incidentally, the current standards have all that's needed for this
discovery-type scenario except possibly a standardId for the data
access services.

-0.5 for auto-description.  It's nice if services could do that,
probably with exactly the same RESOURCE we might have in datalink,
but getData experience has told us that the pain for the data
provider in embedding a full service description in the metadata
response is much smaller than the pain of the client writer to have
to go out to all the data access services mentioned in the results of a
multi-service query to obtain their interface specs -- and you need
that if you want to provide a UI.


How's that for a christmas present?


(duck)

That bad?

Sorry.

Season's greetings,

        Markus