Actually, Source and Target *are* specified in each DataStaging element, if applicable. From the viewpoint of the consuming service, the Source child of a DataStaging means something like "from URL" (to fetch from that URL in stage in), and the Target child of a DataStaging respectively means in deed something like "to URL" (to store at). In fact, the element names could be something different (i..e. "FetchFrom" and "StoreAt"), but then they may confuse other people. That's how standards are like, I presume. :o)
Cheers, Michel
Taking the view from the thread, I'll try to make the meaning of <Source/> and <Target/> more precise. The consuming system will ensure the file identified <FileName/> will have its content originate from the source url, not necessarily fetched, it might be mounted / copied / cached. For <Target/>, the post-condition after the job is finished is that the file resource at the target URL will be identical to (or appended from) the file content on the execution system. The file might be staged-out *after* the job, or streamed during the job, the only guarantee is it will be available after the job has finished. I think the dilemma in pinning down the semantic of DataStaging is because JSDL does not imply the consuming system must be a job execution system. Even talking about "after the job is finished" might assume too much in the context of JSDL. William --- William Lee @ London e-Science Centre, Imperial College London -- --- Software Coordinator --- A: Room 380, Department of Computing, Imperial College London, Huxley Building, South Kensington campus, London SW7 2AZ, UK E: wwhl'@'doc.ic.ac.uk | william'@'imageunion.com W: www.lesc.ic.ac.uk | www.imageunion.com P: +44(0)20 7594 8251 F: +44(0)20 7581 8024 --- Projects ---------------------------- GridSAM: http://www.lesc.ic.ac.uk/gridsam Markets: http://www.lesc.ic.ac.uk/markets ICENI: http://www.lesc.ic.ac.uk/iceni -----------------------------------------