Andreas Savva wrote:
I've had a look through the document; here are some comments:
I'm answering these as I understand them. Points I don't answer are ones where I'd just be agreeing with Andreas. :-)
2. Executable is defined as a mandatory element in the same way as in the JSDL PosixApplication. Given the discussions we've had in the context of the EMS Scenarios this should probably be optional (0-1) since the location may not be known until deployment is finished. (This isn't an issue for the HPC profile.)
Perhaps the right thing to do would be to leave it optional in this spec and then profile it to be mandatory in the HPC Profile. The advanced cases we were considering today lie outside the scope of the HPCP, but this spec is still quite possibly useful for them.
3. Donal changed the Argument type from normalizedstring to string. If I recall correctly there was a very long and heated discussion around this in the past (but, happily perhaps, I can't recall details). Could someone who was involved in the definition of this element followup?
The difference is that xsd:normalizedString trims spaces and xsd:string does not. For arguments, it is sometimes necessary to have leading or trailing spaces. Occasionally, you even need args that are nothing but whitespace. What this spec is supposed to do is to indicate that whatever the implementation does, it must get the argument quoting right so that (near[*]) arbitrary arguments can be given.
4. Working directory - In contrast to Donal's comment I think if this is not present it should not be created.
If the user doesn't give a working directory, it's up to the implementor to do some default way of handling this. Some systems will want to do this by running in the home directory, and others will want to create a new per-job directory. The only files that the user should count on being there are those that they have staged there themselves. (If the user does not specify any stagings, they must obviously not be relying on any relatively-named files at all. Their choice.) Whatever the implementor does, they should document what they do in that case. The HPC Profile may wish to restrict this. (I'd recommend that they do just that!)
Btw, I am really curious here, how is a user going to specify that they want a job to run in their home directory, wherever that place may be? Surely the exact location may differ from machine to machine.
This spec (and more particularly the HPC Profile) isn't about defining portable jobs anyway. After all, requiring an executable pathname isn't even close to portable, and nor is there any mechanism for dealing with differences in path separator between platforms. (At least nobody is trying to suggest that MacOS 9 should be used as a HPC platform; the directory separator scheme there was *much* different...)
5. Why was GroupName dropped?
Not portable to non-POSIX platforms I think. Donal. [* You'd still be limited by the XML 1.0 spec, and there's the whole separate business of understanding the character encodings actually used. Perhaps the spec should say something there, since it is likely that just copying the bytes from the input document won't work. ]