[ogsa-hpcp-wg] [jsdl-wg] Re: Minutes for OGSA HPC Profile telecon (Aug 18 2006)

[Andreas Savva]

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