Multi-dimensional Data Access minimal requirements

[Douglas Tody]

On Tue, 11 Mar 2014, Ray Plante wrote:

> Note that what you are calling "DataAccess" is the purpose of the
> AccessData specification (now being written up by Pat).  And, yes, it
> can be implemented independently of SIAv2.  In previous versions of
> SIAv2 (as Doug mentioned), the access-data capabilities was not yet
> split out.

The queryData and accessData capabilities have always been separately
implementable and callable service capabilities.  Both are still
image-specific capabilities required for the full range of image access
functionality.  What has changed is that they are now to be described in
separate specifications, in part due to the complexity of accessData for
things like advanced cube data access.

Note, these capabilities can still be integrated together into a single
image data access service.  The capabilities would still be separately
callable, i.e., accessData could be used by itself if desired.

See the older email excerpted below.

 	- Doug


----
>From patrick.dowler at nrc-cnrc.gc.ca Tue Jan  7 12:52:59 2014
Date: Tue, 7 Jan 2014 12:06:53 -0800
From: Patrick Dowler <patrick.dowler at nrc-cnrc.gc.ca>
To: "dal at ivoa.net" <dal at ivoa.net>
Cc: Douglas Tody <dtody at nrao.edu>
Subject: Re: WD-SIA-2.0, going forward

On 07/01/14 10:21, Douglas Tody wrote:
> My summary at this point would be that we have agreement on adding
> additional query parameters, and on an integrated SIA service, but one
> which is composed of separate capabilities described in more than one
> document for logistical reasons

If by "integrated SIA service" you mean that the implementer supports 
multiple capabilities in a single service, then yes we agree: an 
implementer can do that. The multiple capabilities could include:

* query
* metadata
* datalink
* access data

for which the current plan is 3 documents. I expect the AccessData 
document to undergo several revisions as we include more access features 
and it may also be the right place to concentrate on self-describing 
custom services, in which case it could be somewhat heavy/abstract 
reading (we have to keep that reasonable to support take-up).

And by integrated, I also include the flexibility feature that an 
implementer can implement a single web service resource and just use 
different REQUEST values *or* they can implement different services (as 
described in a previous message).

[...]