I uploaded a new version of the spec. with a number of additions and changes. Some are editorial; some content. Changes: - Moved IP statement to the back per GFD template - Adjusted style of appendices - Adjusted style of back end sections - Adjusted style of TOC - re-arranged sections - Minor changes to fix pseudo-schema multiplicity (missing '?') - Added a couple of references - Added pseudo-schema appendix (do we want to keep this or not) (michel) - added new units (michel) - added arguments/argument (michel) - added limits (donal) - changed id to sid (schema and spec need cross-checking) - added 'name' attribute to FileSystem - removed redundant 'Description' sections & changed name of jsdl:description type elements to Description in the spec (this was agreed some time back.) - added newer schema at the back. This is the one from gridforge and so not the absolute latest one yet. - added a first draft for the processtopology section; https://forge.gridforum.org/projects/jsdl-wg/document/draft-ggf-jsdl-spec/en... -- Andreas Savva Fujitsu Laboratories Ltd
Andreas, thanks for the release. A couple of remarks/comments (also to the schema and pseudo schema): 1) ch 4.2.2.2 and 4.2.2.3 (bandwidth and storage units) I can understand your point here. I don't know why SI did not standardise Zebibits and Yebibits, but thinking of the speed of development in IT, these categories will soon be reached. On the other hand, there will be more evolved version of JSDL, so we still will have the chance to add these units. In short, just drop them. :-) 2) ch. 5.1.1 JobDefinition There's a mismatch here between spec 0.9.3 and the latest available schema regarding the attribute "JSDLVersion". The specification defines this attribute, the schema does not. Which is the correct version? As far as I understood the discussion (and the action point I got last Tuesday), the attribute JSDLVersion passes away, and the machine readable(!) version is encoded in the namespace (the year/month pattern). The specification then can still state "version 1.0" and define the normative namespace according to some GGF guideline. 3) ch. 5.1.1.5 JobDescription pseudo schema Here's a mismatch again. The latest available schema (and pseudo schema) show the attribute "sid" instead of "id". 4) ch. 5.1.4 Profile The spec refers to "jsdl:Description", but the schema and the pseudo schema do not. They need to be changed. 4) ch. 5.2.1 JobIdentification The pseudo schema and the schema show "jsdl:Description". Ch. 5.2.1.5 also shows "jsdl:Description" here, but the list of sub elements still refers to "JobDescription". 5) ch. 5.4.1 Application element THe spec refers to "jsdl:Description", but the schema and pseudo schema do not. They need to be changed. 6) ch. 5.4.6 Arguments / ch. 5.4.7 Argument element The definition and the examples are inconsistent. The example to start Apache2 on a Windows box indicates that empty jsdl:Argument elements are allowed, but the definition does not mention this at all. Proposal: Extend the definition of jsdl:Argument to allow empty elements, as long as at least one jsdl:Argument element is non-empty. This relaxes a bit the constraints on a JSDL document creator, but increases a bit more the parsing and validation burden on the JSDL document recipient. I can live with that. 7) ch. 5.5.17 OperatingSystem The spec refers to "jsdl:Description", but the schema and pseudo schema do not. They need to be changed. 8) Normative References The URL for SI prefixes (we do not mess with SI units here!) is http://www.bipm.org/en/si/prefixes.htm - the binary prefixes can be found at http://physics.nist.gov/cuu/Units/binary.html Cheers, Michel
On Mar 10, Michel Drescher loaded a tape reading:
6) ch. 5.4.6 Arguments / ch. 5.4.7 Argument element The definition and the examples are inconsistent. The example to start Apache2 on a Windows box indicates that empty jsdl:Argument elements are allowed, but the definition does not mention this at all. Proposal: Extend the definition of jsdl:Argument to allow empty elements, as long as at least one jsdl:Argument element is non-empty. This relaxes a bit the constraints on a JSDL document creator, but increases a bit more the parsing and validation burden on the JSDL document recipient. I can live with that.
I do not understand this. Empty strings are valid arguments on many platforms, so no collapsing should be possible. In other words: <Arguments> <Argument>arg1</Argument> </Arguments> and <Arguments> <Argument>arg1</Argument> <Argument></Argument> <Argument/> </Arguments> can not be considered equivalent! The first corresponds to a shell syntax like: some-program "arg1" while the second is: some-program "arg1" "" "" karl -- Karl Czajkowski karlcz@univa.com
On 10 Mar 2005, at 12:46, Karl Czajkowski wrote:
On Mar 10, Michel Drescher loaded a tape reading:
[...]
I do not understand this. Empty strings are valid arguments on many platforms, so no collapsing should be possible. In other words:
<Arguments> <Argument>arg1</Argument> </Arguments>
and
<Arguments> <Argument>arg1</Argument> <Argument></Argument> <Argument/> </Arguments>
can not be considered equivalent! The first corresponds to a shell syntax like:
some-program "arg1"
while the second is:
some-program "arg1" "" ""
Karl, do you have examples for me? I never saw programs that take empty command line arguments, so I did not consider this being a use case at all. Cheers, Michel
Karl,
do you have examples for me? I never saw programs that take empty command line arguments, so I did not consider this being a use case at all.
It's part of the POSIX and Unix models, so I don't see the need for a use case. It would be bizarre to not be able to express what argc/argv can express. Here are examples of the echo command properly interpreting empty strings which it concatenates into a space-separated list of all the arguments: moraine::karlcz[~] echo a b c a b c moraine::karlcz[~] echo a "" b c a b c moraine::karlcz[~] echo a "" "" b c a b c moraine::karlcz[~] echo a "" "" "" b c a b c karl -- Karl Czajkowski karlcz@univa.com
On 10 Mar 2005, at 13:22, Karl Czajkowski wrote:
Karl,
do you have examples for me? I never saw programs that take empty command line arguments, so I did not consider this being a use case at all.
It's part of the POSIX and Unix models, so I don't see the need for a use case. It would be bizarre to not be able to express what argc/argv can express. [...]
Ok then, I don't mind. I'll send Andreas an updated version of the spec (based on 0.9.3). Cheers, Michel
participants (3)
-
Andreas Savva -
Karl Czajkowski -
Michel Drescher