[jsdl-wg] [Fwd: Proposed extension]

[Alexander Papaspyrou]

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/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: OpenPGP digital signature
Url : http://www.ogf.org/pipermail/jsdl-wg/attachments/20060730/767c9996/attachment.pgp