[jsdl-wg] [Fwd: Proposed extension]

[Michel Drescher]

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