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

[Markus Demleitner]

Doug,

On Wed, Jan 15, 2014 at 10:22:13AM -0700, Douglas Tody wrote:
> On Wed, 15 Jan 2014, Markus Demleitner wrote:
> >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?
> 
> This is simply incorrect, as detailed in my previous emails.  With
> automated virtual data generation (already present in SIAV1 for the past
> 12 years or so), a client can get analysis-optimized images from a
> sufficiently capable service, with just a standard SIA query specifying
> the region of interest, followed by a HTTP GET.  Furthermore they can
> get them from multiple services simultaneously with a uniform broadcast
> query, without having to know the details of the data being accessed, or

With our SSA getData proposal (now withdrawn in favour of datalink),
we show that exactly the same thing can be done with what's currently
called accessData, in a uniform, simple, and comprehensible
interface.

> the details of the service capabilities, e.g., whether or not it
> implements accessData and what is actually implemented.

Are you suggesting that chances for uniform uptake are larger if the
same functionality -- server-side data processing -- is exposed in
two largely overlapping ways, one of which has fairly tricky
semantics with lots of fallbacks, defaulting, and a requirement to
punch holes into various encapsulations?  If so, I beg to differ.

> cutout service followed by an HTTP GET.  SIAV2 (as originally proposed)
> is still equally simple, just more capable.  It is important to keep the
> simple things simple - we can add advanced capabilities and still

Simplicity is achieved not by adding features but by removing them,
and with 1.5 pages of prose "mode" certainly isn't trivial.  From an
server implementor's perspective, I'll have to do something pretty
close to "accessData" anyway if I wanted to add mode.  Having to do
"mode" on top is *additional* effort and does not simplify anything.
It just messes up my code and adds quite a few spots to mess things
up.

>From a client implementor's perspective, mode would be a nightmare
as with all the optionalities and fallbacks, service behaviour would
be largely unpredictable -- unless I'd retrieve a solid bunch of
metadata (that we'd yet have to define), but if I do this, why not
retrieve the service metadata for accessData, which is something I'd
probably want anyway?

If you really think there's a sweet spot in the complexity space for
simple cutout vs. archival service, do it the right way and make it
two separate capabilities with different standardIds (or if you must,
two values of REQUEST).  Straightforward, simple to implement,
predictable to the client.

Cheers,

          Markus