WD-AccessData-1.0-20140312

[Mark Taylor]

On Thu, 25 Sep 2014, Markus Demleitner wrote:

> On Mon, Sep 22, 2014 at 07:27:44PM +0200, François Bonnarel wrote:
> >       2 ) As I told Markus several times nothing prevent anybody to
> > build a "primitive type parameter" service for Access data
> > functionalities  along the  lines of a "service descriptor" as is
> 
> Let me just briefly stress why I think that's beside the point: This
> is *not* about the server side and the legality of services there.
> 
> Atomic parameters are about the *client* side.  They are the only
> scheme I'm aware of that allows clients to provide robust, rich,
> cross-server interfaces to server-side data processing services[1],
> at least as long as we do not have a comprehensive, well-thought-out,
> widely deployed and sufficiently generic data model for... data.  And
> I'm not wild about holding my breath until we have that.
> 
> In order to give clients a chance to use the same parameter names and
> values on different services, we need standardisation of the usual
> parameters (e.g., through the three-factor semantics); without it,
> cross-server cutouts or rebinnings or whatever will be unfeasible.

I'd like to back up the point that Markus is making (again) here.

A more flexible parameter interface (Francois, "current draft") can
give you the option to do more things, but makes it harder to
discover from the interface itself what can be done.  A less flexible
(Markus, "primitive parameter type") interface tends to restrict
the capabilities that can be offered by the service, but gives the
client a better chance to work out without any prior knowledge
how to get the most from a newly encountered data service.

The former will allow more capable interaction in a "guided interaction"
scenario, that is between client/service pairs that already basically
understand each other (e.g. what would be a sensible query),
typically because a user or developer is in a position to adjust
client behaviour in terms of his/her human knowledge about the service.

But if you want "unguided interaction", that is to allow client
software to interact with services without having in the loop a
human who has prior knowledge about the target services, it will
work better in the latter model.

Both are useful scenarios, but IMHO unguided interaction, though
harder to get right, is closer to what the VO is trying to do.
Guided tends to look good at the stage of demos or early
implementations, but unguided is likely to deliver more benefits
when, or if, use becomes widespread.

Of course it's a balancing act: the art of designing a good interface
is to retain the benefits of both approaches as far as possible.
I haven't looked hard enough at the specifics of AccessData to
say for sure which side of this particular argument I'm on, but
Markus's arguments sound persuasive to me.

Mark

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/