A group of requests and a description of how the requests are organized into 
a logical sequence of events (AND, OR, XOR, etc ... relationship) as well 
as datasets which may be used by requests

MergeRequests { id=[xs:ID] }
    RequestID { idref=[xs:IDref] }
       ....
    ChooseBetweenRequests { id=[xs:ID] }
        RequestID { idref=[xs:IDref] }
    SetupRequestDependancy { id=[xs:ID] }
        RequestToBeDoneFirstID { idref=[xs:IDref] }
        RequestWaitingForInputID { idref=[xs:IDref] }

Example: A XXTask will depend (or reference) a XXX aplication. Purpose 
is to allow versionning. 

Below, some ideas from DIAL
Dataset{  identity=[xs:ID], 
               mutability=[locked,appending], 
               location=[virtual,logical,physical,staged,mixed],
               composite=[xs:boolean]
            }
Contentlist
             ContentKey { type=[xs:string] }

In SUMS, we implemented a numFilesPerHour. This gave an indication of 
the input rate for a request. The request would then be split into sub-jobs 
according to available resources (CPUtime limit associated to a queue). A 
job would end up with 100 files each for example ... while the dataset would 
be of several 1000 files. BUT, input may be implemented with a different 
concept than files. For example, input can be events, tracks, gene 
sequence, etc ... This tries to generalize the idea.

Total Memory (Virtual + RAM). Distinction is not relevant to users ??

Symetric of input ... Note that the type of storage is not specified here (like 
if the storage is NFS, AFS, Db, etc ...). The rate combined with the unit 
size will obviously limit the possibilities of where the jobs can run. This 
implies that this resource alone may map to several low-level JDL 
requirements (TransferRate, Type from the StorageDevice element 
in Glue CE, or event connection speed if we speak of db)

For easier handling of initialization, end-task garbagge collection and task
wrap up, we may want to define initialization/finalization special requests.
Those could be defined once, and re-used for every job generated by a
single request. 
Also, there may be a need to do a unique request (task) for all jobs (not
for each jobs).

This element may be removed later (only a placeholder for later considertaion).
Ideally, outputs are themselves datasets and currentely, input/output are
non-symetrical.

In the newly proposed U-JDL, application and task are merged.

Either a jar or a class name

The location of the JAR file containing the main class

The arguments to use to execute the JAR file.

Minimum may be used for dispatching purposes. A process will not start unless the available resource is above this minimum.

If unspecified, there are no known upper limits. If specified, this value indicates that the job will use this value as  maximum quanta of the resource will be taken.

Rate estimated by the user for his request.

In MB