On Apr 26, Donal K. Fellows loaded a tape reading:
Hi everyone!
...
I suggest that the attribute should be called jsdl:filesystem (or rather, whatever we use in DataStaging but I don't remember for sure right now) and we might use it like this fragment:
<jsdl:Application> <jsdl:ApplicationName> Gaussian </jsdl:ApplicationName> <jsdl-exec:POSIXApplication> <jsdl-exec:Input jsdl:filesystem="HOME"> input.txt </jsdl-exec:Input> <jsdl-exec:StackSpaceLimit> 8388608 </jsdl-exec:StackSpaceLimit> </jsdl-exec:POSIXApplication> </jsdl:Application>
This seems as reasonable as the other magical approaches. It only prevents arbitrary string splicing like we have in GRAM... we use a ${VARIABLE} substitution rule in string fields like args and environment settings. The only thing more general might be some attribute to enable such a rewrite rule on a particular string element field? E.g. by the ever faithful URI or QName "extensible enumeration type" to indicate how such a filesystem string name is merged into the target element.
We'd need to decide what predefined virtual filesystems to support, of course. Or have we done that already? :^)
Donal.
Could this be handled using a more open content model? I am still not sure I understand the use case, e.g. who defines the virtual labels and their meaning. Could they ever be created dynamically by some external negotiation or stateful process, meaning the label really only means something to the client and for the provider it is just an arbitrary space in a pool? karl -- Karl Czajkowski karlcz@univa.com