In the absence of a revised JSDL document w/ all the work items completed that were generated at GGF-13, here are some notes I took for myself on the basic structure and scope... Please note that there are two ways to look at the resource constraints (this is one of the most metaphysical aspects of job scheduling): 1) implied performance requirements via physical resource selection 2) qualitative features of the job configuration I think the JSDL view is more towards (2), meaning that the resource constraints describe basic "shape" of a job. They need to be complemented by more performance-oriented constraints including wall-clock lifecycle and/or performance of hardware (CPUs, interconnects, disks, hierarchical RAM, etc.). I think JSDL is extensible enough to insert performance constraints into its structure, so I do not know if it is better to do this or use an external annotation format for composing JSDL, performance metrics, and WS-Agreement. karl JSDL cheat sheet ---------------- There is an explicit understanding that the base JSDL doc element allows expression of homogeneous parallel jobs, and sequential jobs. To express heterogeneous parallel jobs, or heterogeneous "alternates" (a Unicore idea?), will require an enclosing context that presents a set of JSDL job documents w/ some way to interpret them for this purpose. In other words, a multi-job like syntax could represent either "do all these simultaneously" or "choose one of these that fits the resource pool". It will take some time for a new draft to settle out w/ all the revision decisions enacted. We pushed a lot of stuff out of scope and tried to fix a lot of warts. Here is a rough sense of the structure, without trying to write a schema right now: JobDefinition JobDescription JobIdentification ? JobName ? Description ? JobAnnotation * JobProject * xsd:any##other User ? ExecutionUserID ? ExecutionGroupID ? UserGroup * xsd:any##other * Application ? ApplicationName ? ApplicationVersion ? ExecutableApplication ? Executable Argument (xsd:string) * Environment (xsd:string) * attr: name=xsd:string Input ? Output ? Error ? WorkingDirectory ? PosixStackLimit ? PosixProcessLimit ? ... PosixMaxFilesizeLimit ? xsd:any##other * xsd:any##other? Resource ? HostName * ResourceCount ? CPUArchitecture ? TotalCPUCount ? TotalRAM ? ... PerResourceCPUCount ? PerResourceRAM ? ... DataStaging * FileName FileSystemID ? CreationMode DeleteOnTermination ? Source ? URL Target ? URL xsd:any##other ? xsd:any##other * xsd:any##other * The Input and Output elements are actually complex structures to do the expected things such as associating source/destination URLs with local filenames or filespaces. The types of many obvious things are xsd:string. The types of the "resource constraint" numerical limits will be a ValueRangeType that basically is something like this: sequence <Exact>xsd:integer</Exact> * <LessThan>xsd:integer</Exact> * <GreaterThan>xsd:integer</GreaterThan> * <Between> <Lower>xsd:integer</Lower> <Upper>xsd:integer</Upper> </Between> * to allow the structured expressionf of their previous "string range value language" which allowed things like: a, b, c, d-e, f-, -g to give a mixed list of values, intervals, and semi-spaces. -- Karl Czajkowski karlcz@univa.com