vos:group vs. uws:JobInfo

[Patrick Dowler]

On Friday 13 August 2010 06:20:34 Paul Harrison wrote:
>  The easiest interpretation comes where the JDL is simply a set of
> application/x-www-form-urlencoded (name, value) pairs such as what is
> produced by a HTML form submission, but this model is fairly restrictive
> when it comes to defining relations between the parameters as you are
> wanting to do here. I think that the only viable solution with this simple
> model is to introduce parameter naming rules that indicate the
> relationships - but this sort of thing quickly reaches its limitations.

I recall that the idea was that a specific service could chose to specify a set 
of parameters to define the JDL *or* specify an XML extension and hook it in, 
but not both. 

In DAL services, parameters are single valued (in the http sense: you only 
have one param=value pair) and multiple values are done using a list syntax. 
This works fine for DAL and hence TAP was able to trivially use the parameter 
list to contain the entire job description. It is true that this is limited, 
but so far as I am aware DAL has not run into the limit.

> The more general idea in UWS is to have a more expressive JDL such as can
> be achieved with XML (though other encodings/ domain specific languages
> are equally valid), and in this case there might not be a simple mapping
> into the individual "parameters" within the JDL.

In our vospace implementation, we were slightly hampered by our UWS library 
only handling POST of parameters (eg application/x-www-form-urlencoded); that 
has since been extended to accept text/xml (a uws job document). We are also 
limited in our current use to requiring authentication and certificates for 
most things so the client was coded to always only ask for https; this we may 
have just not run into this multiple-pairs of values thing.

I think there are 3 options:

1. naming convention or the grouping attribute: I find it ugly as it introduces 
all these odd error conditions and complex code to make sure both halves of 
the pair are found and put together

2. allow multiple protocol/endpoint pairs, but use a single parameter with a 
pair of values, eg:

<uws:parameter id="datasource">
ivo://ivoa.net/vospace/core#httpput
DELIMITER
http://some.server.com/put/the/data/here
</uws:parameter>

where DELIMITER needs to be something never allowed in the URI or URL. Then 
one could have multiple datasource=<protocol>,<value> in the request. It still 
means application code has to interpret/parse this manually and I don't 
generally like using an (xml) parser and still having some parsing to do :)

3. use an XML format for the structure and use that inside the uws job 
document; I see that the <transfer> has a <protocol> element with a child 
<endpoint> element, which seems to provide the necessary structure... maybe 
this could be a <transfer> element with multiple <protocol> inside. Thus the 
request (job) has a <transfer> with multiple <protocol> and the result 
(job.results.transferDetails) has a <transfer> with just the chosen/used 
<protocol>.

So, assuming I understand the use of the xs:any in the UWS schema, instead of 
the example in 5.4.4 (pushFromVOSpace) one could POST this:

<uws:job>
<uws:jobId/> 
<uws:ownerId xsi:nil="true"/> 
<uws:phase/> 
<uws:startTime xsi:nil="true"/> 
<uws:endTime xsi:nil="true"/> 
<uws:executionDuration>0</uws:executionDuration> 
<uws:destruction xsi:nil="true"/> 

<vos:transfer>

<vos:target>vos://nvo.caltech!vospace/mydata1</vos:target> 
<vos:direction>pushFromVoSpace</vos:direction> 
<vos:view>ivo://ivoa.net/vospace/core#defaultview</vos:view> 

<vos:protocol uri="ivo://ivoa.net/vospace/core#httpput">
    <vos:endpoint>http://some.server.com/put/the/data/here</vos:endpoint>
</vos:protocol>

<vos:protocol uri="ivo://ivoa.net/vospace/core#ftpput">
    <vos:endpoint>ftp://some.other.server.com/put/the/data/here</vos:endpoint>
</vos:protocol>

</vos:transfer> 
</uws:job>

where I obviously gloss over the necessary xml schema declarations :-)

I don't really like #1 or #2; having more or less finished implementing both a 
VOSpace 2.0 service and client recently, there's plenty of XML already and #3 
would not be a burden to implement or use. In fact, I think it would be 
easier.

-- 

Patrick Dowler
Tel/Tél: (250) 363-0044
Canadian Astronomy Data Centre
National Research Council Canada
5071 West Saanich Road
Victoria, BC V9E 2M7

Centre canadien de donnees astronomiques
Conseil national de recherches Canada
5071, chemin West Saanich
Victoria (C.-B.) V9E 2M7