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.