Michel Drescher wrote:
here're a couple of new and updated documents:
draft-ggf-jsdl-spec-0.9.5-01.doc The JSDL specification document itself. Contains all changes and decisions from the last phone conference.
jsdl-0.9.5-01.xsd The JSDL schema consistent (well, I hope so...) with the latest specification document.
apps-posix-0.1.xsd The schema defining the POSIXApplication element.
POSIXApplication-Example.xml A sample XML file using the POSIXApplication extension.
Looking pretty good (modulo the outcome of the UserId discussion ongoing in the other thread). Issues I've spotted on a quick read-through: 1: Section 6 is now inconsistent in its references to other terms (ProcessCount and TileSize are under POSIXApplication) 2: It is probably a good idea to move the section after the normative extensions section as well, in order to minimize forward references. 3: Resource/FileSystem/DiskSpace does not specify the units (only sensible values are bytes or 512-byte blocks; we probably want to specify bytes). 4: Many examples throughout Resource/FileSystem and R/FS/DS are out of date. 5: Subsubsection titles for 5.5.14 and 5.5.15 have extra spaces. 6: 8.1.3.1 states that argument whitespace must be collapsed. What does this mean? I've had use-cases in the past where I've wanted to pass pure-whitespace arguments to programs... 7: Examples in 8.1.3.6 sometimes use (old) Arguments element. 8: Input, Output and Error elements should state that we're talking about filenames relative to some known location (the job's working directory?) 9: First sentence of 8.1.10.1 should read: "This element is a positive integer that specifies the soft limit on the duration of the application's execution, in seconds." 10: All limit elements (8.1.10 through 8.1.22) should have a "Limit" suffix to their names for clarity. 11: Minor typos in 4.2.2.5.2's source expression. The translation is correct. 12: Figures 1 and 2 *still* need reworking so they don't look like embedded powerpoint... :^) 13: Need to state (in section 1) that JSDL is intended for use both on the Grid and elsewhere. This is important because it informs a number of our design decisions which would have been different had we been able to assume that we were encapsulated within some kind of service context. That's everything I can think of after a quick run-through. I might think of more later. :^) Donal.