Donal, Donal K. Fellows wrote:
Andreas Savva wrote:
I still can't remember the discussions on this but I believe this was the reason we allowed empty argument elements and said they must not be collapsed. The question I have if you change the argument type to a string is then why do you need multiple argument elements?
Also I don't have a big problem with restricting definitions (e.g., by removing the filesystem attribute in this application extension) but I do have a problem with changing types for identically named elements.
I've tried looking up the word "collapsed" in relation to XML, and it seems to be fairly meaningless. Instead, these things are best defined in terms of XSD facets, and given the general requirements (no trimming, no internal replacement of whitespace sequences, no processing at all) xsd:string is the exact type we need. If the main JSDL spec says anything else, I think we can say that it's in error. :-)
I don't think 'collapsed' was used in any XML-specific sense; rather it was probably used in the spec to mean that empty argument elements should not be discarded. Actually the spec should say clearly that an empty argument element maps to an empty string. It shows examples of this but it should say so in the definition. (One for the tracker.) Though I tend to agree with you that 'string' is more appropriate(*) than 'normalizedstring' I would still like to know why we chose normalized string in the first place. I'll put this in the tracker as well and I'd like to ask that this part of the definition of argument in the HPC application extension be kept pending until we have a discussion of this issue, probably at GGF18. Is this agreeable? (* if only because I can imagine cases where I'd want to pass a 'tab' character)
Donal, are you saying that if the directory is not present it should be up to the implementation to decide what to do? I read your comment as saying that the specification should state that the directory should be created.
There are 3 cases: 1: User specifies existing directory - must not be created! 2: User specifies non-existing directry - must be created! 3: User does not specify directory. This case is up to the implementor but will probably follow one of the two patterns: 3a: Use existing "well-known" directory, e.g. $HOME. Implementation must document what directory will be chosen. 3b: Create new directory with "random" name so that jobs are isolated. Implementation must state that this will happen.
I do not believe that the behaviour of all existing batch systems is the same in case 3 FWIW; lower-level ones will tend to 3a (as it assumes less) and higher-level ones will tend to 3b (as it isolates better).
I don't agree that all existing batch systems create a non-existing directory for case 2, and I would not want to see a MUST or SHOULD for this in the document. A MAY might not be objectionable.
Yes, but it is still a common use case to run a job with 'home' being the working directory, or in a subdirectory relative of home. I think a way to specify that without giving the full path name isn't too much to ask.
Not sure I agree. The HPC Profile stuff is for a very restricted case.
I might be willing to agree if the limitations are described adequately in the document. -- Andreas Savva Fujitsu Laboratories Ltd