WD-AccessData-1.0-20140312

[Markus Demleitner]

Dear DAL group,

On AccessData in principle -- is there anything that can be done
with the current, 18-page draft with lots of complex syntax and many,
many open questions that could not be done with the simple annex to
Datalink as proposed in

http://www.ivoa.net/pipermail/dal/2013-December/006602.html

If not, could we not at least seriously discuss why we should embark
on all this complexity and special casing?  Promised, I'll shut up
with this if I see one or more use cases the simple thing cannot
cover but the complex draft credibly can.  

I already have one IMHO important task that I at last cannot see in
the complex one: Figuring out what values of the parameters might
actually yield data.

And on one of the special cases:

On Thu, Mar 13, 2014 at 03:54:09PM -0700, Patrick Dowler wrote:
> 
> 
> On 13/03/14 03:31 PM, Petr Skoda wrote:
> >the biggest mistake of SIA 1.0 is there is not primary the concept of
> >filters built-in - I am just in troubles trying to access the multi
> >colour survey.
> >
> >I do not believe the most use cases can be solved by stating
> >wavelengths in BAND....

> Or are you talking about creating a virtual R-band image out of a 3d
> cube? If you are talking about a virtual image from a cube, the only
> kind of access that is in scope for AccessData-1.0 is simple
> extraction is subsets. All other kinds of operations are to be
> considered later in 1.x

I believe Petr is thinking about multi-extension files and getting
just one extension out of this, referenced by band name.  I agree
this is an interesting use case, as the question what the "right
thing" to do when e.g., doing cutouts from multi-extension files is
tricky indeed and needs to be worked out before we REC anything on
data access services.  But the difficulty is, at least for me,
retrieval semantics and not parameter syntax.

For that, I think it's again plain we do not want to allow "either
range or filter name" in BAND, *if* people agree on the (1)-(3) from
http://www.ivoa.net/pipermail/dal/2014-March/006674.html (and nobody
has disagreed).

How would you define that parameter's metadata?  Are you seriously
considering

<PARAM name="BAND" datatype="char" arraysize="*" unit="m">
  <VALUES><MIN value="3e-7"/><MAX value="5e-7"/>
    <OPTION value="V"/><OPTION value="B"/>
</PARAM> ?

A string with a unit, and a wavelength of V meters?  V being between
3e-7 and 5e-7?  Oh, horrors.  Please, please, let's not even go near
such a thing.

The good news is that something like this can easily be pulled off
sanity-preservingly:

<PARAM name="LAMBDA" datatype="double" unit="m" ucd="em.wl">
  <VALUES><MIN value="3e-7"/><MAX value="5e-7"/>
</PARAM>
<PARAM name="LAMBDA_WIDTH" datatype="double"...>

and *on top of that*

<PARAM name="BAND" datatype="char" arraysize="*"
    ucd="meta.code;instr.filter">
  <VALUES><OPTION value="V"/><OPTION value="B"/>


Future versions (building on top of PDL, say) could then say that you
cannot combine LAMBDA and BAND, and that LAMBDA has cardinality 0..1,
whereas BAND has 0..n (if you want), but that's (a) basically
understood (PDL) and (b) dispensable for version 1.0.


Cheers,

          Markus