Folks,

I think we are having conflicting goals here.
(Technical goals, not personal ones ;-)

On one hand, we have the "S for simplicity" in SAGA, and we must keep it.

On the other hand, we have the necessity to support JSDL, future JSDL
extensions, or any other types of job decscriptions that people want to use.
(And still might to be invented.)

Assume, JSDL++ (whatever it will look like in near future) will become a
widely adopted standard. (Or anything else, doesn't matter in the following.)
Then, SAGA implementations will have to use JSDL++, and to form JSDL++ from
SAGA job descriptions. Simultaneously, users are likely to use JSDL++
themselves, and may wnat to use JSDL++ to express their resource needs.
At this point in time, SAGA will sit in the middle, and it may be very clumsy
to first translate from JSDL++ to a SAGA job description, and then back to
JSDL++ somewhere "down under" in the implementation.

For the very purpose of SAGA as a universal and simple grid API, it has to: 
- be independent of job description standards (mostly simpler than them)
- support job description standards

My suggestion:

SAGA should have one class of job descriptions, and the possibility to
create subclasses for more specific job descriptions (like JSDL).
Such subclasses could be defined as separate extension documents (just like
gridcpr). (Or was it "resource descriptions"???)

With this approach, users could still write programs that are independent
of the underlying job submission machinery, having a simplified view on
jobs and resource attributes etc. etc.
At the same time, subclassed job/resource descriptions could be
"passed through" transparently from the API to the implementeation, without
being converted back and forth, a process that is very likely to loose some
important details.

Is this a route to go?

Thilo

On Tue, Feb 13, 2007 at 06:28:58PM +0100, 'Andre Merzky' wrote: