vos:group vs. uws:JobInfo

[Matthew Graham]

Hi Pat,

I would be happy with #3 as well if it is allowed.

	Cheers,

	Matthew

On Aug 13, 2010, at 5:06 PM, Patrick Dowler wrote:

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