[jsdl-wg] [Fwd: Proposed extension]

[Peter Lane]

What I've been doing with GRAM is to add an extension element to  
JobDescription instead of JobDefinition which is an array of  
JobDescription elements. This allows for the top-level JobDescription  
to act as a defaults document. This is useful if you're doing things  
like parameter sweeps. The executable, directory, etc can be  
specified once and only those items that differ between subjobs are  
specified explicitly in the subjob JobDescription elements.

I also think the ID attribute is perhaps redundant. JobIdentification  
has a JobName element that seems like it should be sufficient for  
uniquely identifying a subjob. Or is this not how the authors  
envisioned JobName's use?

I'm wondering if such extensions are really within scope of the JSDL  
specification, though. It seems more like an application-specific  
extension. Perhaps the workflow elements should be in a  
WorkflowApplication extension to the top-level Application element,  
and then the POSIXApplication extension would be specified for the  
subjob JobDescription elements. This would ruin using the top-level  
JobDescription element for subjob defaults (doing both would be too  
confusing), but I'm ok that.

Peter

On Jul 30, 2006, at 6:35 AM, Alexander Papaspyrou wrote:

> Hi Michel, all,
>
> Michel Drescher schrieb:
>>>> NOTE: The multi job extension requires two backwards compatible  
>>>> changes
>>>> to the JSDL v1.0 schema itself:
>>>> a) jsdl:JobDescription gets an "id" attribute of type xsd:ID
>>>> b) jsdl:JobDefinition allows more than one jsdl:JobDescription  
>>>> element.
>
> sounds decent to me. We are doing exactly that with a home-brew XML
> dialect in D-GRID (http://www.d-grid.de/) for what we call  
> workflows --
> which is pretty much the same as dependent jobs.
>
>>>> I will update/create the necessary specification documents after  
>>>> the
>>>> next round of rotten eggs. ;-)
>
> No eggs today ;)
>
>>> Interesting. I used to think in terms of doing job dependencies  
>>> like you
>>> illustrate in example2, but recently I've been considering  
>>> treating a
>>> job (or rather the outcome of that job) as a resource in itself.  
>>> This
>>> would mean that, once a job has been labelled, all the other  
>>> things need
>>> to do to depend on it (i.e. follow in the job-graph) is to put a
>>> reference to that job in their Resources element. I don't know  
>>> whether
>>> this would permit the definition loops, but maybe loops are only  
>>> ever
>>> useful for things like parameter sweeps anyway. (Need more real
>>> use-cases to decide that!)
>
> Hm, I'd separate these (as Michel suggested for the bi-directional  
> deps
> further down) to keep it simple. The "output from A is input for B"
> could for the moment be handled by the service which gets the JSDL and
> orchestrates the execution.
>
>> Eventually we decided that this type of model is very much  
>> compatible to
>> human brains, but (unfortunately) not to relatively dumb computer  
>> brains.
>
> I agree, since this needs deeper thought.
>
>>> It doesn't solve the other thing that ought to be expressed  
>>> though. It
>>> is sometimes *really* useful to be able to specify that two jobs  
>>> must
>>> execute at the same time (otherwise the job engine might just run  
>>> the
>
> Agreed, this should be added with the deps extension.
>
>> a) Rename jobgroup:Dependencies to jobgroup:Constraints
>> b) Have an abstract element named jobgroup:COnstraint
>> c) Use XML Schema substitution groups for types of constraints:
>> c.1) jobgroup:Dependency for unidirectional dependencies
>> c.2) jobgroup:Coupling for jobs that need to co-execute.
>>
>> Any more suggestions?
>
> What about a single dependency type with attributes like "before",
> "after", "togetherwith", "whenfailed" and so on? The attributes could
> then be externalized to an enumeration and extended over time without
> breaking the core.
>
> Comments, eggs and/or tomatoes?
>
> Greetings,
> Alexander
>
> -- 
> Dipl.-Inform. Alexander Papaspyrou      | 44221 Dortmund, NRW  
> (Germany)
> Robotics Research Institute             | phone  : +49(231)755-5058
> Information Technology Section          | fax    : +49(231)755-3251
> Dortmund University                     | web    : http://www.irf.de/
>