Folks, meanwhile I figured out (thanks Joel!) that the Argonne mailman doesn't like ZIP files. :-( I attached a renamed ZIP file - rename it to "Archive.zip" and it should work out of the box. Cheers, Michel -------- Original Message -------- Subject: Proposed extension Date: Fri, 07 Jul 2006 13:55:10 +0100 From: Michel Drescher <Michel.Drescher@uk.fujitsu.com> To: JSDL WG <jsdl-wg@gridforum.org> Folks, sorry for the delay - my fault. I sent the revised proposal to the "wrong" mail address jsdl-wg@ggf.org. Obviously, this mail address is a dead end. :-( 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. ;-) Cheers, Michel -- Michel <dot> Drescher <at> uk <dot> fujitsu <dot> com Fujitsu Laboratories of Europe +44 20 8606 4834 -- Michel <dot> Drescher <at> uk <dot> fujitsu <dot> com Fujitsu Laboratories of Europe +44 20 8606 4834
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. ]
Hi Donal, all, Donal K. Fellows wrote:
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. ;-)
[...]
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!)
I know exactly what you mean. I had pretty similar thoughts back then when we carved out the *real* UNICORE (if I may be so bold ;-) - back in 1997. I had had the idea to model a Task so that it has a list of "input slots" and a list of "output slots". Each slot was supposed to be a typed slot, so that you could couple two tasks by associating two compatible slots, one being an output slot, and one being an input slot. Eventually we decided that this type of model is very much compatible to human brains, but (unfortunately) not to relatively dumb computer brains.
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.
Touché. :-) My riposte is as follows. Instead of limiting ourselves to add only dependencies - which are unidirectional constraints - we should broaden the scope, e.g. by allowing non-dicectional (and/or bidirectional) associations. The following may solve your problem: 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? Cheers, Michel -- Michel <dot> Drescher <at> uk <dot> fujitsu <dot> com Fujitsu Laboratories of Europe +44 20 8606 4834
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/
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/
Hi Peter, all Peter Lane wrote:
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.
You got me confused here. You allow a jsdl:JobDescription to contain other jsdl:JobDescription elements? I reckon that this would be a change to JSDL rather an extension, right?
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?
The jsdl:JobName element is of descriptive nature instead of uniquely identifying a job. So in that sense, I think a xsd:ID may be necessary on the atomic job description, using "atomic" here inn the scope of defining a single execution job (leaving data staging out of scope for the moment).
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.
I can understand both viewpoints, having this topic in scope of JSDL or not. The JSDL WG should decide whether defining a workflow is in scope of JSDL, or out of scope, or perhaps if a split strategy is an appproach in that a basic worklow (based on dependencies) is in scope, but any complex constructs using perhaps BPEL is out of scope. The reason why I raise this scope question is that this most likely affects the structure of the associated work. While having (partially or as as whole) workflows in scope could end up changing the JSDL core element structure, while completely deferring workflow from JSDL means that the workflow definition will use the current JSDL element set without any proposed changes (whether backwards compatible or not). [more stuff, i.e. answer to Alex, further down.]
On Jul 30, 2006, at 6:35 AM, Alexander Papaspyrou wrote:
[...] 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.
This is an interesting twist and sounds quite promising. I'll explore that path further, thanks. Cheers, Michel -- Michel <dot> Drescher <at> uk <dot> fujitsu <dot> com Fujitsu Laboratories of Europe +44 20 8606 4834
Michel Drescher wrote:
Hi Peter, all
Peter Lane wrote:
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.
You got me confused here. You allow a jsdl:JobDescription to contain other jsdl:JobDescription elements? I reckon that this would be a change to JSDL rather an extension, right?
No, I am using a wrapping element for the subjob list: <jsdl:JobDescription> . . . <gram:SubjobDescriptions> <jsdl:JobDescription> . . . </jsdl:JobDescription> <jsdl:JobDescription> . . . </jsdl:JobDescription> . . . </gram:SubjobDescriptions> </jsdl:JobDescription> Thus namespace="##other" is not violated.
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?
The jsdl:JobName element is of descriptive nature instead of uniquely identifying a job. So in that sense, I think a xsd:ID may be necessary on the atomic job description, using "atomic" here inn the scope of defining a single execution job (leaving data staging out of scope for the moment).
I guess I don't see anything really wrong with referencing a descriptive job name that only has to be unique within the context of the JSDL document. Peter
Peter Lane wrote:
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?
Actually, the problem with an ID attribute is more subtle, in that the uniqueness constraint upon it is defined purely at the document level. In the world of XML documents living at URLs, the wider disambiguation is done by the URL of the overall document, but that's not useful with JSDL because job submission templates will typically not have a (fixed) URL before the submission. I suspect that to fix this we need a GUID *somewhere* in there, and that the source of the GUID has to be either the user or (more likely) the client software that injects the JSDL document into the system. That would allow JSDL consumers to know unambiguously whether they've seen the document before without having to do a full canonicalize-and-compare. With a bit of work[*], I might even come up with a scenario where a full comparison would fail despite two JSDL documents really being the "same" in some higher-level sense. Things get quite complex when you have job rewriting/optimization services in the mix, but a GUID lets the "what is identity" decision be taken at a the outermost - and hence most abstract - level. Donal. [* Which I'd rather not do, being somewhat lazy. :-) ]
Donal, careful, you are mixing two concepts here: intra-document uniqueness and inter-document uniqueness. Donal K. Fellows wrote:
Peter Lane wrote:
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?
Actually, the problem with an ID attribute is more subtle, in that the uniqueness constraint upon it is defined purely at the document level.
There is no subtlety with xsd:ID and xsd:IDREF. They are defined exactly for what they are supposed to do: intra-document uniqueness. Full stop. The proposal never intended to promise more than intra-document uniqueness as this is what is required by intra-document dependencies.
In the world of XML documents living at URLs, the wider disambiguation is done by the URL of the overall document, but that's not useful with JSDL because job submission templates will typically not have a (fixed) URL before the submission.
Talking about inter-document uniqueness touches the domain of naming, which is the topic of another working group, the OGSA-Naming WG.
I suspect that to fix this we need a GUID *somewhere* in there, and that the source of the GUID has to be either the user or (more likely) the client software that injects the JSDL document into the system. That would allow JSDL consumers to know unambiguously whether they've seen the document before without having to do a full canonicalize-and-compare.
All this may be valid issues, but not for the proposal. If you need to fix inter-document uniqueness, add a QName to the outermost JSDL document element and use an appropriate GUID algorithm that fits the QName requirements. Or use the stuff the Naming-WG is proposing.
With a bit of work[*], I might even come up with a scenario where a full comparison would fail despite two JSDL documents really being the "same" in some higher-level sense. Things get quite complex when you have job rewriting/optimization services in the mix, but a GUID lets the "what is identity" decision be taken at a the outermost - and hence most abstract - level.
Separate the concerns. Hence separate the mechanisms of JSDL document identification and document element identification (to use some other terms rather iter- and intra-documennt blah blah). Cheers, Michel -- Michel <dot> Drescher <at> uk <dot> fujitsu <dot> com Fujitsu Laboratories of Europe +44 20 8606 4834
Alexander Papaspyrou wrote:
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.
Are the dependencies which they are modelling "typed the same"? If so, then describing the type of dependency as a decoration (probably an attribute, but that's a minor XML encoding matter) on the element is fine. If not, we'd be making an unholy mess. I don't know if they are the same or not, BTW. It's just the question that needs answering. Since you appear to have thought about this a bit longer than I have, I'll export my question to you. :-) BTW, the "before" and "after" types seem at first glance to be symmetric views on the same dependency arc. Can we do without one of them? Let's try to keep down the number of ways of describing any particular concept! Donal.
Hi Donal, all, Donal K. Fellows schrieb:
Alexander Papaspyrou wrote:
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.
Are the dependencies which they are modelling "typed the same"? If so, then describing the type of dependency as a decoration (probably an attribute, but that's a minor XML encoding matter) on the element is fine. If not, we'd be making an unholy mess.
Yes, I would model them as one single type with the dependency as a decoration. And yes, you are probably right that not doing this would result in an utter mess...
I don't know if they are the same or not, BTW. It's just the question that needs answering. Since you appear to have thought about this a bit longer than I have, I'll export my question to you. :-)
I am currently working on a prototype XSD for this and will post it to the list ASAP (have to find my fireman suit first).
BTW, the "before" and "after" types seem at first glance to be symmetric views on the same dependency arc. Can we do without one of them? Let's try to keep down the number of ways of describing any particular concept!
Hm, they seem to be. I'll have to rethink this. Since this dependency stuff is somewhat subtle, I'll try to construct a few examples. -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/
Hi Michel, Donal, all, Alexander Papaspyrou schrieb:
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.
okay, as threatened before, here is my proposal for a job dependency extension. It uses a very simplistic construct for specifying inter-job dependencies, but might IMHO be sufficient. Thoughts? Kind regards, 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/
Hi All, I just have a few questions/comments concerning the discussed extension. 1. I understand that there might be several dependencies related to a single job. If so, you assume a conjunction or disjunction of dependencies? In other words, ALL dependencies or ANY of dependencies must be met (e.g. jobs finished) to start a job? In my opinion both cases are sensible and justified so it would be useful to enable determining it in this extension. However, dependencies would have to be probably grouped into groups concerning particular jobs. 2. I understand that the condition 'before' means to start a job before other job has been started? I think the most general way to express conditions is to allow specifying after which state of other job a given job must start (e.g. after start, finish, failed, canceled etc.). The problem is that as I remember well definitions of job states are not a part of the JSDL specification. 3. Have you considered passing output data from workflow jobs as input data to another jobs in JSDL? To make it independent from chosen nodes there should be a possibility to express input/output files as logical identifiers unique within a workflow. Just my 2 cents... Best regards, Ariel ----- Original Message ----- From: "Alexander Papaspyrou" <alexander.papaspyrou@udo.edu> To: "Michel Drescher" <Michel.Drescher@uk.fujitsu.com> Cc: "Donal K. Fellows" <donal.k.fellows@manchester.ac.uk>; "JSDL Working Group" <jsdl-wg@ggf.org> Sent: Tuesday, August 29, 2006 4:24 PM Subject: Re: [jsdl-wg] [Fwd: Proposed extension] Hi Michel, Donal, all, Alexander Papaspyrou schrieb:
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.
okay, as threatened before, here is my proposal for a job dependency extension. It uses a very simplistic construct for specifying inter-job dependencies, but might IMHO be sufficient. Thoughts? Kind regards, 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/ ---------------------------------------------------------------------------- ---- <?xml version="1.0" encoding="UTF-8"?> <xsd:schema targetNamespace="http://schemas.ggf.org/jsdl/2006/06/multijob/jobdeps" xmlns:jsdl-jobdeps="http://schemas.ggf.org/jsdl/2006/06/multijob/jobdeps" xmlns:jsdl="http://schemas.ggf.org/jsdl/2005/11/jsdl" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:import namespace="http://schemas.ggf.org/jsdl/2005/11/jsdl" schemaLocation="../../1.0_final/jsdl.xsd" /> <!-- ************************* ENUMERATIONS ************************* --> <xsd:simpleType name="ConditionEnumeration"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="before"></xsd:enumeration> <xsd:enumeration value="after"></xsd:enumeration> <xsd:enumeration value="togetherwith"></xsd:enumeration> <xsd:enumeration value="onsuccess"></xsd:enumeration> <xsd:enumeration value="whenfailed"></xsd:enumeration> </xsd:restriction> </xsd:simpleType> <!-- ************************* TYPES ************************* --> <xsd:complexType name="Dependency_Type"> <xsd:sequence> <xsd:element name="Condition" type="jsdl-jobdeps:ConditionEnumeration"> </xsd:element> <xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"> </xsd:any> </xsd:sequence> <xsd:attribute name="idref" type="xsd:IDREF"></xsd:attribute> <xsd:anyAttribute namespace="##other" processContents="lax"></xsd:anyAttribute> </xsd:complexType> <xsd:complexType name="DependencyList_Type"></xsd:complexType> <!-- ************************* ELEMENTS ************************* --> <xsd:element name="DependencyList" type="jsdl-jobdeps:DependencyList_Type"> </xsd:element> <xsd:element name="Dependency" type="jsdl-jobdeps:Dependency_Type"> </xsd:element> </xsd:schema>
Hi Ariel, all, Ariel Oleksiak schrieb:
1. I understand that there might be several dependencies related to a single job. If so, you assume a conjunction or disjunction of dependencies? In other words, ALL dependencies or ANY of dependencies must be met (e.g. jobs finished) to start a job? In my opinion both cases are sensible and justified so it would be useful to enable determining it in this extension. However, dependencies would have to be probably grouped into groups concerning particular jobs.
yup, true. I just overlooked that, sorry. In our own, proprietary stuff, we handle this. I will incorporate the conjunction/disjunction notion into my proposal.
2. I understand that the condition 'before' means to start a job before other job has been started?
Yes. However, you are right that this is ambiguous. I agree that the best way to handle this would probably be to couple the condition to job states, but...
I think the most general way to express conditions is to allow specifying after which state of other job a given job must start (e.g. after start, finish, failed, canceled etc.). The problem is that as I remember well definitions of job states are not a part of the JSDL specification.
that is the problem. Alas, I don't see a solution for this. Any thoughts on this?
3. Have you considered passing output data from workflow jobs as input data to another jobs in JSDL? To make it independent from chosen nodes there should be a possibility to express input/output files as logical identifiers unique within a workflow.
Yes, I am currently working on this. My idea was to add an ID attribute to the <jsdl:DataStaging> element, which then could be referenced in other <jsdl:DataStaging> elements; I will put this together during the next days and then happily discuss the implications on the list. Regards, 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/
participants (6)
-
Alexander Papaspyrou -
Ariel Oleksiak -
Donal K. Fellows -
Michel Drescher -
Peter G. Lane -
Peter Lane