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