WD-AccessData-1.0-20140312

[Douglas Tody]

(So, we are back to the endless discussion of parameter syntax...)

On Thu, 25 Sep 2014, Mark Taylor wrote:
> 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.

But this just gets to the heart of the difference between, e.g.,
SIA, SSA, AccessData, etc., and the use of something like DataLink
to expose arbitrary service interfaces.

AccessData is a good example of a service class that exposes complex
functionality, with a nontrivial access model underlying the service
interface.  Mere generic interface discovery will not be sufficient to
use such a service; the client application will need to understand the
specific service class and the semantics of its access model.
Furthermore, multiple service implementations scattered about the world
will have to implement the same standard interface and access model, to
be usable by client applications.  A standard service interface and
access model is mandatory in this case (although it can be versioned).
"Guided interaction" can thus be used to provide a better, more capable
interface to the service class.

DataLink on the other hand can expose arbitrary service types, providing
a generic discovery mechanism that a client can use to discover their
service interface.  This is a good thing to have, and is required to
expose arbitrary local services (and can even be used to document the
interface to standard services), but it is not a substitute for having a
standard interface and access model for complex standard services.

 	- Doug



On Thu, 25 Sep 2014, Mark Taylor wrote:

> 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.
>
>
> 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/