Co-wranglers, I (again me...) have a list of questions (extracted from the mail of Karl Czajkowski mentioned last week): 1) Argument list handling in jsdl:Application Basically, the modeling of command line arguments in a whole string is ... cumbersome? I know, it works, but it looks ugly. Instead, I'd like to propose the following (in PseudoCode): <Application ... > ... <Arguments> <Arg order:xsd:positiveInteger>xsd:String</Arg> </Arguments>* ... </Application> Every content in the jsdl:Arg element would be converted to quoted strings if it contains whitespaces. Example: Consider an application "print.exe" that sends a file to a named print queue. The default queue is used when no print queue name is given. "print.exe -p dj720c example.txt" (1) "print.exe example.txt" (2) "print.exe 'C:\Program Files\Dummy\help.txt'" (3) The XML snippets could be as follows: ... <Arguments> (1) <Arg order="1">-p</Args> <Arg order="2">dj720c</Arg> <Arg order="3">example.txt</Arg> </Arguments> ... <Arguments> (2) <Arg order="3">example.txt</Arg> </Arguments> ... <Arguments> (3) <Arg order="2">C:\Program Files\Dummy\help.txt</Arg> </Arguments> ... Note: XML itself seem not to impose any order to elements with the same name contained in the same parent element. So we have to invent our own ordering mechanism (as done by the order attribute). 2) Versioning This topic might be slipped, so I would like to raise it again. Call me a nag bag, but is this superfluous information to contain "jsdl-1..1.xsd" in the namespace definitions? As an alternative, I propose the following namespace that also serves as a version identifier: "http://www.ggf.org/jsdl/2005/03/jsdl/" or "http://www.ggf.org/jsdl/2005/03/" where "http://www.ggf.org/" - is the shared domain of all GGF standards "jsdl/" - is the JSDL common domain "2005/03/" - is the version of the specification "jsdl/" (or sth. else) - is the sub-specification (if we want to think of any) 3) Storage/bandwidth units At the moment, we use a mixed set of units. SI defines two distinct sets of units: One based on 10, and one based on 2 (adopted by the IEC), having the 10 based units the normal prefix (like K, M, G, T, P and E) and the 2 based units the prefixes Ki, Mi(!), Gi, Ti, Pi and Ei. I propose to use the SI units. For JSDL2, I propose to switch to an OID based system for these kind of units. 4) Reservations What about the concept of resource reservations? Some initial thoughts: - Use reservation tokens in JSDL to refer to previously made reservations (with means out of scope of JSDL) - Incorporate/emend the job description with means to make reservations, so the reply to such a JSDL document would give the reservation token to put into another JSDL document to actually use the reserved resources 5) JSDL 2.0 issues list I would like to get some topics to be put as research/development candidate for JSDL2. 5.1) more structure for Java applications Quote from Karl's mail:
-- more structure for java -- jar versus bytecode class -- native compiled java? -- like executable but java-style parameterization -- class w/ Main() to invoke -- language version -- external class dependencies? -- supported JVMs (java portability 50% myth)
Cheers, Michel