UWS POST PHASE=RUN

[Matthew Graham]

Hi,

The obvious exampled of a document-based JDL is VOSpace where data transfers are coordinated via UWS. The transfer resource that is posted to initiate a job is hierarchical and so could be difficult to map to a parameterized form. It gets stored under the jobInfo element for the UWS representation of the job.

	Cheers,

	Matthew

On Nov 3, 2014, at 11:22 PM, Paul Harrison wrote:

> On 2014-11 -03, at 17:11, Patrick Dowler <patrick.dowler at nrc-cnrc.gc.ca> wrote:
> 
>> 
>> IIRC,  document-based JDL used the jobInfo part of the UWS document (which allows an xs:any child element do be defined and store the document as-is (e.g. a vospace <transfer> document). That predated the addition of <parameters> which was, as Paul outlined, which was added to support DAL services...
>> 
>> I think the intent was that mixing document + parameters was not allowed, which does make sense. Maybe it should have been defined such that <parameters> is a document to stick under <jobInfo>. In hindsight that would be more clear on the "or" usage, but may have obscured that little xs:any that allows other kinds of documents.
>> 
>> Pat
> 
> Hi Pat,
> 
> in UWS the JDL need not be XML based at all - so is not necessarily representable even under the <jobinfo> element -and I agree that there was no intent that the generic JDL and DAL “parameter/value” mechanism could be mixed - which is why I was suggesting that there be some conventions written into the standard to make this separation clearer and make the language of the standard stronger in section 2.1.11 - so that the suggestions become “should”s rather than “best practice”.
> 
> Paul
> 
>> 
>> On 03/11/14 04:29 AM, Paul Harrison wrote:
>>>>>    * When an XML document is submitted as single parameter, how must it be stored in the UWS service: as one parameter (with byReference=true) or as some individual parameters which has been extracted from the XML document?
>>> I think that it should be stored as a single “parameter” - there should be no attempt by the generic UWS to interpret the document.
>>> 
>>> I think that it would probably be a good convention that if the initial POST has a application/x-www-form-urlencoded encoding, then the UWS can assume that the parameter/value pair mechanism can be used.
>>>>> 
>>>>>    * In the case where a submitted XML document must be stored as one parameter, what must be its name/id (the id which must be written in the "id" attribute of the XML node "parameter")? Since it has been submitted alone, I presume that no name has been given, and so that one must be invented and associated to it by the UWS service. That method could work because it is not possible to create parameters after the job creation. Is it correct?
>>> It would probably be a good idea to give a conventional name to this parameter - e.g. JDL, and the UWS 1.1 document should specify what the conventional name should be.
>>> 
>>>>> 
>> 
>