Hello Donal, many thanks for replying, hope you (or other group members) also had time to look through the document. I am new to JSDL business, but have quite some experience with "real" job description languages used for great variety of applications in EDG/LCG/gLite (JDL) and NorduGrid/ARC (xRSL), thus I have some questions that perhaps are just FAQ of this group, see below.
a) This should be possible through either the existing subelements of the POSIXApplication element, or through extension. However I'd love to see more input from you on this as part of the development of the next version of the spec.
There are several elements that can be easily added; runtimeenvironment is just one of them. What is this group's criteria for an element to be added to the specs? What kind of arguments should I present to support each case? Would it be sufficient to tell that few hundred users find it convenient, and so do Grid m/w developers and site owners?
b) This should be done by wrapping the JSDL singletons inside some larger XML dialect that describes the relationship of the basic jobs to each other. Although we want to support workflows, we've always pushed the workflow bit of it out of scope so we can get agreement on the rest of everything. :^)
I don't think that describing several jobs in one script has anything to do with workflow. It's up to the workload management system to interpret it, but for the user's convenience it would be nice to include into JSDL a possibility to specify several jobs. No need for a "larger XML dialect", just one more super-element. Here's a use case: I want to submit 10000 jobs that differ only in one input parameter. I have a tool that generates JSDL; and I'd hate to fill my disk with 10000 small files. You are not going to create a dedicated workgroup to produce a two-line spec that describes JSDL concatenation, are you?
c) I think we're punting this one out to WS-Agreement (over a space of JSDL terms). It gets really complicated otherwise as you start to try to describe spaces of coupled terms...
Eh, nobody promised it's going to be easy :-) I understand that XML is just a markup language, not quite suited for task definition, because task description normally includes conditions "if then else", relations "and", "or", and negations "not". For example, "buy X amount of apples if they are red, else buy Y amount of pears and Z amount of bananas". This is a single task, these are not separate jobs. It does not describe workflow, because it does not specify in which shop these apples or pears should be purchased (doesn't even say it should be the same one), or when, and not even the price. JSDL presently can't describe such a job. I don't even see how two separate job descriptions can be merged by another *XML* dialect into one - XML is not really made for it. In real life, I've had plenty of jobs like "if a site has outbound connectivity, stage in this, else stage in something different". Globus' RSL allows this, and I'm sure it's a part of job description, not workflow. It is an instruction for the execution site, not for the workload manager/broker.
In summary, "why isn't it possible now", "out of scope", and "out of scope". But that's just a bit short and I think you'll prefer the longer outline above. ;^)
I'd like to learn what is the scope, I guess - and where to submit things that are out of it :-) Oxana