I have checked the typo fix.
Thanks!
Andreas

Mass Update

Published as GFD.56 27 November, 2005.

This will now be published as GFD-R.056.  Thanks
very much to the editors/authors for efforts on
this important document.

The GFSG voted to approve this document today.
I'll do a final pass, then this will be published.
Thanks to the authors for work on this document!

We have reviewed the comments from the AD and made some minor revisions to the specification. See draft 28 uploaded to this tracker.

Briefly, with numbers referring to Ramin's comments in a previous post:
 
1. Updated
 
2. Decided not to make any changes since the list is not meant to be complete.
 
3. Confirmed with Ramin that this formatting problem is specific to his MS Word.
 
4. Added text to remove this ambiguity.
 
5. Section 3 (Scope) discusses these issues and we think more detail is not appropriate in a normative document. The WG is thinking about a Roadmap 
document and that may be a better place to discuss the choice of features. We have added cross-references from the Application and Resource sections 
back to Section 3.
 
6. Confirmed with Ramin that there is no such example in the specification.
 
7. JSDL 1.0, by design, does not support default values for elements not appearing in a JSDL document. As such, this text is appropriate---it's a 
warning to the user. We have added text to the specification to make the 'no defaults' policy explicit.

We've also made a small number of other revisions, mainly to reconcile minor differences between the specification and the schema. A change-tracked 
version relative to draft 25 is available from the WG's gridforge site. See
https://forge.gridforum.org/projects/jsdl-wg/document/draft-ggf-j
sdl-spec/en/27

Thanks
Andreas

Thanks.  This will be discussed the next GFSG standards call
(November 8?).

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

I suggest this standard be named either
GS-JSDL or
GGF-JSDL
GGF desperately needs a clearer branding and our incoherent
labelling does not help
e.g. we have
GridFTP
DFDL
JSDL
Info-D
OGSA-DAI etc.
They should be clearly associated from name with GGF

I made same comment on WS-Agreement

This looks very good to me - the writing is clear,
the headings and formatting is fine, and it seems to
address a valuable area.

The next step for this is GFSG 15-day review, which I
will try to have complete by the GFSG conference
call on July 15.  After that will be 60-day public comment.

This is in initial editor review.  I'll send feedback 
shortly.  Thanks for this submission!