[jsdl-wg] [Fwd: Proposed extension]

[Donal K. Fellows]

Michel Drescher wrote:
> Please find attached two proposed JSDL extensions. The attachment
> contains the schemas, and a list of examples.
> 
> 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.
> 
> I will update/create the necessary specification documents after the
> next round of rotten eggs. ;-)

This time, I'm commenting on the multi-job extension and ignoring the
other one (since it's late!)

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

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
two processes through the same best-effort batch queue, resulting in
effective serialization of the execution and causing both sub-jobs to
fail[*]). although this is a dependency of sorts, it is an oddball case
because each is dependent on the other and yet neither is a resource
that exists before the other starts (this is why it is the output of the
job that is the resource BTW). As such, it needs a different method of
expression.

Hopefully you can extract some useful suggestions out of this brain
dump. :-)

Donal.
[* I've seen coupled-application demos fall apart because of this. ]