JSDL provides a job submission description language for computational jobs. The scope has been limited to the basic 
requirements for computational jobs. That means, there is no support yet for workflows, scheduling information or a 
general resource description language. However, the authors clearly address these issues as future steps beyond the 
scope of JSDL. Moreover, they give insight how to extend the current spec. 

The current version seems well conceived within the given scope. Therefore, I see no reason why this document should not
 move forward in the document pipeline.

Specific
1.	At one point the references, e.g. WS-Agreement [WS-AG], might be updated in the reference section and the text.

2.	Section 3.2: 
A distinction is made for temporal scheduling, data-dependent scheduling and workflow-dependent scheduling. Reading 
about the temporal scheduling, one might ask what happened with space-scheduling, the question where a job execution. 
While the given list is not conceived to be exhaustive, it might be sensible to add an entry or alter the "temporal 
scheduling" to include time and location scheduling.

3.	Sect. 4, and other locations
I am not sure whether it is just a problem of my Word version, but the document and my print had problems with 
consistent line spacing. I encountered this problem first in this Section. Between "cannot be satisfied." and "Note, 
however".
Such problems occur on several locations in the doc, especially the references on page 61/62 are mal-formatted.

4.	Sect 5.2.4:
Value "dontOverwrite": Maybe, it should be made clear for this value what the semantic implications for this value is if
 a file exists. For instance, that no file action will take place if the file already exists.Looking at Sect 6.5.475ff, 
I was asking myself whether it is clear that a file should be deleted on termination even if it was not created by this 
job because it already existed before.

5.	Sect 6.1.2:
Within the JobDescription Element, was there a clear reason why the Application and the Resources Element have a 
multiplicity of "zero or one". In both cases, I could see a need for having a "zero or many" relation; e.g. the job uses
 or is a collection of applications; or needs a set of different resources. I assume that the WG had some discussion on 
this issue. Therefore, it might be helpful to have some lines in the text why this limitation was introduced.

6.	Sect. 6.4.1, Sect 6.4.18.1, Sect 6.4.28:
In 6.4.28, an example is given in which several "individualCPUCount" occur within one job. However, according to Sect 6.
4.1.5 and 6.4.18 the multiplicity of "individual CPUCount" is "zero or one". This is an inconsistency.
There may be good reason to allow multiple individual CPU counts as given in the example. However, if that is allowed, I
 have several questions how the other "Individual*" elements can be used in practice if there is the possibility to have
 multiple "IndividualCPUCount" elements. For instance the relation of Individual time memory etc. may rely on the 
particular definition CPU set. This would require some referencing/addressing/ordering of the elements, which might make
 everything quite complicated.

7.	Sect. 6.4.28:
For practical implementations, I am not sure whether it is a good idea to have the non existence of a TotalResourceCount
 yield to the result that "consuming system "MAY choose any value".