<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi all,<br>
Le 15/09/2014 22:20, Patrick Dowler a écrit :
<blockquote cite="mid:54174A21.7040300@nrc-cnrc.gc.ca" type="cite">
<br>
This was an aside to my previous post, but I thought it best to
separate (TL;DR and all that).
<br>
<br>
As an aside, for RESTful web services it is true that service
descriptor cannot currently describe how to call them. It can tell
the users about the service via the standardID, but this is
considerable effort (maybe by GWS?) to figure out how to describe
RESTful services. In general, I don't see a generic REST client
being able to do something sane without grok'ing the semantics of
the various resources so IMO we need to not worry about REST in
DataLink-1.0 and
<br>
<br>
Even then, if you make a descriptor for the vospace {nodes}
capability, you cannot really include a reference to a FIELD with
"vos" URIs to use with it... it is maybe a bad example because
with vos URIs the client can in fact extract the
resourceIdentifier so it could find the right service descriptor
that way (vs lookup in registry).
<br>
<br>
In our vospace impl, we have a custom resource with fast
parameterised transfer negotiation: that can be described fully
and a generic client could successfully get a file using it...
this is in the vospace 2.1 WD.
<br>
<br>
<br>
I expect the first real case that will come up in DataLink is
trying to describe an AccessData type of service that is async and
using UWS for job creation and management. We'll need some way to
say that the capability is async. The standardID essentially
requires clients to "know" the service spec and doesn't currently
cover custom servcies... or can it?
<br>
<br>
- for a standard service, just specify the normal standardID and
expect the client to know if that is UWS or not
<br>
<br>
- for a custom sync service, there is no standardID
<br>
<br>
- for a custom async (UWS) service, set standardID to be the UWS
standard (generic async job)
<br>
<br>
</blockquote>
OK, but why having no standardID in second case ? Laurent's idea was
to use this to EXPLICITLY say it is not standard . The standardID
value should be something like ivo://ivoa.net/<b
class="moz-txt-star"><span class="moz-txt-tag"></span>nostd<span
class="moz-txt-tag"></span></b>/Get or
ivo://ivoa.net/nostd/Rest. Doing this everything will be explicit
looking at standardID<br>
<br>
In case you have ivo://ivoa.net/<b class="moz-txt-star"><span
class="moz-txt-tag"></span>nostd<span class="moz-txt-tag"></span></b>/Get
you knox that you have to look for accessURL and Parameters of the
HTTP-GET query in the same descriptor. Rest advertizes there is no
description. accessURL should be anything we have.<br>
<br>
Best regards<br>
François<br>
<br>
<blockquote cite="mid:54174A21.7040300@nrc-cnrc.gc.ca" type="cite">In
all cases, the input parameters are described. Is that a total
perversion of standardID? Would it be wrong to do the same in a
VOSI-capabilities record for a custom async service? I think the
two should carry the same info so the latter is the real
question...
<br>
<br>
<br>
<br>
</blockquote>
<br>
</body>
</html>