[jsdl-wg] DataStaging concerns

[Karl Czajkowski]

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 at univa.com