[jsdl-wg] Issues for the teleconference tomorrow

[Michel Drescher]

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