[jsdl-wg] DataStaging concerns

[Peter G.Lane]

Hi all,

Forgive me if I'm reiterating on a topic.  I've only be reading up on 
JSDL since yesterday.  I have a few concerns about the DataStaging 
section.  Primarily, I'm wondering if it really makes sense to have it 
as part of the core schema.  I think it would be better to have 
extensions like POSIXApplication for more specific DRM configurations.  
Here are some of my thoughts:

1) There's still controversy over whether staging should or should not 
be integrated into a DRM.  As far as I can tell, for example, the BES 
doesn't have any plans to implement staging.  DRMMA makes this 
optional.  If BES ends up using JSDL, wouldn't this be a violation of 
the spec which requires each element to be supported in some way?

2) There's no distinction between a stage-in or stage-out flavor of the 
staging directives.  I guess it's up to the service to decipher this so 
that it can perform the staging at the appropriate point in the life 
cycle.

3) I don't particularly like that the DataStaging sections include an 
option to remove the file at the end of the job.  If I'm staging out 
data then this doesn't make a whole lot of sense.  I'd much prefer a 
separate section which explicitly lists all the files that are to be 
removed from the submission machine after the job has been completed.  
This would also cover the case of data that is created rather than 
staged in but still needs to be removed after job completion.

4) Based on the current GRAM incarnation, it would be nice to let RFT's 
transfer request description extend a base staging schema and then use 
that in the JSDL document rather than adding a bunch of extensions to 
DataStaging.  This is similar to how I'd want to go about using 
POSIXApplication.

Thanks in advance for any responses...

Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2782 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/jsdl-wg/attachments/20050519/f7c2f67c/attachment.bin