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