Hiya,
I've done some big cropping to the email. See comments below below:
The schema limits the possible values to several _types_ of applications
like
scripts, java classes, sql queries, etc. But how e.g. fortran
compilation could
be specified? Imagine that you don't know the details about the location
of
the fortran compiler and the compiler vendor.
The schema uses a union of NMTOKEN and a set of enumerations (as you
list above). Therefor you can either use one of the pre-defined
enumerations or derive your own set of NMTOKENS that can be used here.
The enumerated tokens were the application types that we have already
identified as being general enough to make part of the core schema.
Perhapses something like "FortranCompile" could go into a specific
extension for your use of jsdl or into a compiling extension set along
with "CCompile" and "JavaCompile". Personally I prefer the latter. At
some stage we may decide that some of these extensions are general
enough to become part of the core jsdl (say version 1.3 spec) in which
case it could be added. Hopefully this gives enough scope for you to
achieve what you need.
We can look at the UNICORE experience and try to configure
the particular applications using the following entities:
a) fields (i.e. partucular file names, argument values,
e.g. "source=a.c", "size=1234")
I see this as being a different interpretation on the Argument element
(which would require using a non-JSDL type for now, though this will
make for a powerful thing to do once we've got JSDL 1.0 out of
the door.)
OK, so non-JSDL Argument could be a solution.
Again this could go along with the ApplicationTypeEnumeration
extensions. You could specify for a new type how to interpret the
Argument elements and/or add extension elements that deal with these. I
don't see jsdl 1.0 being the final version and see that as people come
up with new extension sets that are useful to a lot of people the jsdl
group may choose to add them into the core spec for future releases. Or
just support certain core extensions.
d) variations (variations of expected results, e.g.
"overwrite" for file operations)
I don't currently see how the current DataStaging element's
CreationFlag
and DeleteOnTermination sub-elements are insufficient. Please explain
further.
Well, file operations can include "copy folder" or "untar file" and can
be
expressed as applications. So such variations can exist.
Hmm, this would suggest that having the ability to extend the
DataStaging element was a good idea. Yes I think you've got a point
here. So that's my vote for an xsd:any in the DataStaging element. We
steered away from putting "copy folder" or "untar file" in the core
spec as so many DRM systems didn't support this. But it would make a
useful extension set.
Hope that helps,
steve..
--
------------------------------------------------------------------------
Dr A. Stephen McGough
------------------------------------------------------------------------
Research Associate, Imperial College London, Department of Computing,
180 Queen's Gate, London SW7 2BZ, UK
tel: +44 (0)207-594-8310 fax: +44 (0)207-581-8024
------------------------------------------------------------------------
Assistant Warden, West Wing, Beit Hall, Imperial College,
Prince Consort Road, London, SW7 2BB tel: +44 (0)207-594-9910
------------------------------------------------------------------------