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