Tricky. It would need to be XTSL like preprocessing on both the client side and on the compute side. I wonder if the differences between Grid and Compute Center would require any specializations. There is much more legacy stuff that DRMAA needs to address that GRAM. -Hrabri
-----Original Message----- From: Donal K. Fellows [mailto:donal.k.fellows@manchester.ac.uk] Sent: Wednesday, April 06, 2005 8:33 AM To: JSDL WG Cc: Rajic, Hrabri; DRMAA Working Group Subject: Re: [jsdl-wg] RE: [drmaa-wg] making a custom file path for output
Ali Anjomshoaa wrote:
we discussed this issue at some length at GGF13 and were unsure as to how to proceed. We would like to be able to reference labeled attributes, but, I think we're still discussing how to implement this issue in the xsd schema depending on current tooling!
I think, unfortunately, our choice of how we implement this in xsd will influence how we specify how to do this in the spec. Clearly this is not ideal and should be the other way round!
On Tue, 5 Apr 2005, Rajic, Hrabri wrote:
Placeholders would be special variables like home directory or job id ($ sign prefixed below), which DRMAA could substitute in job attributes like the output path:
drmaa_set_attribute( $jt, DRMAA_OUTPUT_PATH, $DRMAA_HOME_DIR/MY_APP/my_job_output.$DRMAA_JOB_ID.out"
Hmm, I have to say that I don't like arbitrary substitutions in XML content, especially in styles like this. (It's one of the bits I do not care for about Ant, BTW.) But the way I'd handle such a problem is through something like submitting the job through a service that applied an XSLT substitution to the document before producing a doc with "ground terms". If you see what I mean.
In the specific case of wanting to have file arguments given to the application made relative to one of our virtual filesystem concepts, there is an argument to be made for some improvement of the JSDL spec. At the moment, the only mechanisms we have for arguments are "relative to the job working directory" or "absolute", neither of which are great for this use-case. (The same argument applies to environment variables, of course.)
Does this brain-dump indicate the sort of area where we need to address some kind of solution? Or are there other cases which will need more refinement before we work out how to fix it all?
Donal.