[jsdl-wg] application abstraction in JSDL (fwd)

[A Stephen McGough]

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
------------------------------------------------------------------------


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/jsdl-wg/attachments/20041125/3ef39018/attachment.html