[jsdl-wg] Issues for the teleconference tomorrow

[Donal K. Fellows]

Michel Drescher wrote:
>         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).

XML (like SGML) is *always* document-ordered (consider an enumerated
list in XHTML where it is not necessary to explicitly number each list
item) and it is part of the basic DOM model. To get real "any order of
elements" specifications in XSD you have to go through considerable
contortions, though you can do it quite shortly if you allow any number
of each of a set of elements in any order.

FWIW, <xs:sequence> is an ordered list, and <xs:choice> is a "one of
these" selection. There is also an "all of these" operator, but it can't
be used with a maxOccurs of more than one for some reason and is
therefore nearly useless. (I've not been able to find the reason for
<xs:all>'s many restrictions; it seems to be a community decision taken
"somewhere" and never publically recorded. Bizarre!)

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

OID? That brings back bad memories. Please give a nice example and
convince me that those memories are wrong... :^)

> 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

Resource reservations are out of scope (i.e. they're embeddable as
extensibility elements).

> 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)

Any sensible suggestions in this area are entirely welcome, though we
need to distinguish between modes of operation. For running of a classic
Java application, supplying the name of the class or jar is sufficient
(there's already an established pattern for such things, and they are
distinguishable normally by the fact that class names virtually never
correspond 100% with filenames without *some* kind of simple mapping).
For other kinds of hosting system, it might be necessary to do other
things, and it would be interesting to hear about them...

Donal.