SIAv2 mode [was: WD-SIA-2.0, going forward]

[Markus Demleitner]

Dear DAL list,

[Text of Doug's mail reorganized a bit to improve discourse
comprehensability]

On Tue, Jan 14, 2014 at 10:32:01AM -0700, Douglas Tody wrote:
> On Tue, 7 Jan 2014, Patrick Dowler wrote:
>> [SIAv2's mode parameter]
> >If so, this is an optimisation of the general case that comes at
> >the cost of coupling this mode parameter in the query capability to
> >the operations available in the access data capability.
>
> Anyway, to get back to the issue of the automated virtual data
> generation (AVDG) capability, if the query can describe virtual data
> products that will be computed only if accessed, and the service
> implementation chooses to use accessData to compute those data products
> (reasonable since accessData likely provides the functionality to do
> so), then of course there can be coupling between the query and
> accessData.  However, this is not done explicitly, i.e. there is no
> explicit coupling.  The client just sees an acref URL, which may or may
> not be invoking accessData internally within the URL.
[...]
> AccessData also does virtual data generation, but comes at it from the
> complete opposite direction: explicit client-directed access instead of
> automated data generation.  But client-directed access is what we need
> for a different type of use-case, repeated precision access to a single
> large image cube being a prime example.

I, frankly, cannot see any difference in total capabilities between a
a service with both "mode" and accessData and accessData exclusively.
There is nothing a client can do with mode that it couldn't do with
accessData alone, no?

But then Pat is right and mode is just a (really minor) optimization
in the query flow: The client gets links to the processed images in
the reply table directly rather than having to produce them itself
based on an accessData specification, which is not really hard.

I agree with Doug that accessData (or, since I'm not a big fan of that
term, server-side processing) is a must, so that's going to stay.
But do we then need "mode" if it doesn't add anything substantial?

In Doug's August 12 draft, "mode" takes up 1.5 pages, which includes
fairly complicated conditionals, things that I'd feel very uncertain
what to do with as a client writer, and the big spec mine[1] that is
multiple query modes; I suspect that for a clear and unambiguous
specification, another pages would be necessary.

For something that's for all I can see just a minor convenience to
the clients, that's a *lot* of spec language and effort.  And quite a
bit of fairly ugly code (as formatting suddenly needs to look at
quite a few input parameters, you need to punch holes in your
encapsulations) in implementation.

I'd say: That's a bad deal.

Cheers,

         Markus

[1] A spec mine is defined as "a few short sentences that blow up
into lots of code lines if implementators step on them"


--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?