Donal: did we lose the xsd:any child of the top-level JSDL document element? If we decided to have a WS-GRAM dialect of JSDL where we just transliterated some of the biggies like our staging clause, I would expect there to be, for example, a single (or three) "RFT element" at the top-level as a peer to the POSIX application and resource sections and zero jsdl:FileStaging elements. The problem Peter is having, I think, is that it would be awkward to try to break the RFT element into separate pieces for placement inside of specific separate FileStaging elements per file. He would like to feel comfortable completely ignoring the JSDL staging model and putting in the WS-GRAM one instead. There are sufficient differences in how WS-GRAM and JSDL understand the filesystem(s) of the computing host and the responsibilities of the submitter and job system such that supporting a "WS-GRAM file management extension" may not be consistent with supporting the "JSDL staging model". I certainly thought this would be possible. Note, this is a technical question in my mind. I realize there is an entirely orthogonal concern about when one "should" use the extension mechanisms in a particular way... in these hypothetical discussions we all bring a lot of assumptions about how other standards will appear. For example, I assume BES will not include staging nor define how BES services respond to FileStaging elements. A BES client expecting interop would not use the JSDL staging nor any other non-BES extensions. Therefore, I do not see a BES + WS-GRAM staging extension as described above to really be more or less interoperable than one that tries to use the JSDL staging syntax. It would be specifically for transitional/legacy use by applications not content to use the interop profile(s). karl -- Karl Czajkowski karlcz@univa.com