Issues for the teleconference tomorrow
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
On Mar 07, Michel Drescher loaded a tape reading:
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.
I think you mean to have the "*" on the Argument element, not on the Arguments envelope, e.g. <Arguments> <Argument>xsd:string</Argument>* ... </Arguments>? I leave the "?" if Arguments is optional... The order attribute is unnecessary. The XML infoset model preserves "document order" for child elements, partly I think as this is critical to a lot of mixed-content approaches from SGML and HTML... The XPath and XQuery specifications are examples of XML specifications that depend on preservation of document order in the infoset, in order to do positional navigation and selection of XML structures. You will not find a statement about this in XSD because the preservation of order in processing is outside the scope of the validation semantics. I think the WSRF and/or WS-BaseNotification activities may also depend on this in a few places, but I am not certain of that.
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.
I agree. To address your "Mi(!)" comment, the "i" is short for "bInary", e.g. "Ki" means "Kilo-binary" and "Mi" means "Mega-binary". It has been proposed that "MiB" would be pronounced "mebi bytes" as opposed to "maybe bites" or "Men in Black" :-) karl -- Karl Czajkowski karlcz@univa.com
Karl, Michel Karl Czajkowski wrote:
On Mar 07, Michel Drescher loaded a tape reading:
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.
Michel, I think the word you were looking for was 'simple.' ;-)
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.
I think you mean to have the "*" on the Argument element, not on the Arguments envelope, e.g.
<Arguments> <Argument>xsd:string</Argument>* ... </Arguments>?
I leave the "?" if Arguments is optional...
The order attribute is unnecessary. The XML infoset model preserves "document order" for child elements, partly I think as this is critical to a lot of mixed-content approaches from SGML and HTML...
Good. I was going to object to the 'order' attribute. (For me that's ugly.) This would be ok.
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.
I agree. To address your "Mi(!)" comment, the "i" is short for "bInary", e.g. "Ki" means "Kilo-binary" and "Mi" means "Mega-binary". It has been proposed that "MiB" would be pronounced "mebi bytes" as opposed to "maybe bites" or "Men in Black" :-)
I could go for this too. (The UR-WG already did something like this, I believe.) -- Andreas Savva Fujitsu Laboratories Ltd
On Mar 08, Andreas Savva loaded a tape reading:
Karl, Michel
Karl Czajkowski wrote:
On Mar 07, Michel Drescher loaded a tape reading:
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.
Michel, I think the word you were looking for was 'simple.' ;-)
It is "simple" right up until you need to pass through strings that have your separator whitespace, or quote marks, or what have you embedded in one program argument! I think it is much simpler to maintain structured data than it is to try to embed funny serializations of structured data into the JSDL info set model. This is particularly so when a consumer of this document needs to translate the structure into some arbitrarily different structure or serialized syntax to safely pass it through local implementation layers. That was certainly our experience in trying to make GRAM RSL sane... I often regretted the fact that we didn't use as much explicit parenthetic grouping for arguments as we did for environment variables, because users often made bad assumptions about where the argument strings were separated versus treated as one string that needed to be "reparsed". Our (pre-WS) RSL parser explicitly represented a sequence of strings in the right-hand side of the "arguments" clause parse, and we had a somewhat standard whitespace, quoting, and quote-escape mechanism to allow people to express any possible argument list. For example: (arguments= foo bar baz ) was a shorthand for: (arguments="foo" "bar" "baz") and you could get whitespace or a stray quote in with: (arguments="foo bar" "baz""spliced") which would render as this in the current proposal: <arguments> <argument>foo bar</argument> <argument>baz"spliced</argument> </arguments> which I certainly think is more obvious than the RSL way. :-) I suppose the only tricky one now would be getting angle brackets in there: <argument><not a tag></argument> karl -- Karl Czajkowski karlcz@univa.com
Karl Czajkowski wrote:
On Mar 08, Andreas Savva loaded a tape reading:
Karl, Michel
Karl Czajkowski wrote:
On Mar 07, Michel Drescher loaded a tape reading:
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.
Michel, I think the word you were looking for was 'simple.' ;-)
It is "simple" right up until you need to pass through strings that have your separator whitespace, or quote marks, or what have you embedded in one program argument! I think it is much simpler to maintain structured data than it is to try to embed funny serializations of structured data into the JSDL info set model. This is particularly so when a consumer of this document needs to translate the structure into some arbitrarily different structure or serialized syntax to safely pass it through local implementation layers.
It's 'simple' and covers many cases but complicated cases make it very complex. :-) Your description of the problems is good and I like having the extra structure. I know argument parsing is a black art. I think our assumption might have been that the contents would go through as-is, unseen and untouched and not our problem. (We did actually allow more than one argument in the distant past.) Andreas
That was certainly our experience in trying to make GRAM RSL sane... I often regretted the fact that we didn't use as much explicit parenthetic grouping for arguments as we did for environment variables, because users often made bad assumptions about where the argument strings were separated versus treated as one string that needed to be "reparsed". Our (pre-WS) RSL parser explicitly represented a sequence of strings in the right-hand side of the "arguments" clause parse, and we had a somewhat standard whitespace, quoting, and quote-escape mechanism to allow people to express any possible argument list.
For example:
(arguments= foo bar baz )
was a shorthand for:
(arguments="foo" "bar" "baz")
and you could get whitespace or a stray quote in with:
(arguments="foo bar" "baz""spliced")
which would render as this in the current proposal:
<arguments> <argument>foo bar</argument> <argument>baz"spliced</argument> </arguments>
which I certainly think is more obvious than the RSL way. :-)
I suppose the only tricky one now would be getting angle brackets in there:
<argument><not a tag></argument>
karl
-- Andreas Savva Fujitsu Laboratories Ltd
Hi Michel I hope to make the call but just in case (still recovering from a cold) here are some comments: Michel Drescher wrote:
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 :
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)
I'm ok with the current definition. (And, no, I wasn't the one to come up with it.) And I'd object putting this on the teleconf agenda; it doesn't feel like a useful discussion to have. My proposal would be for some brave soul (Michel?) to do a short note on how all GGF schema namespaces should look like and send it to the GGF Editor. (It doesn't have to be an formal document or anything, maybe an email would be ok.) I've seen this kind of discussion in more than one group and it would be nice to have some simple guideline.
3) Storage/bandwidth 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
We've discussed this sort of thing in the past and put it out of scope of version 1.0. (And I think that's where it should stay for now. I don't want to go down the path of adding just-one-more new feature at this moment.)
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)
I think we should have a post-v1 tracker and put these things there. (I can create a post-v1 tracker if the chairs agree.) -- Andreas Savva Fujitsu Laboratories Ltd
Hi Andreas, Michel,
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)
I'm ok with the current definition. (And, no, I wasn't the one to come up with it.) And I'd object putting this on the teleconf agenda; it doesn't feel like a useful discussion to have.
I agree with Andreas on both points, current definition is usable and we shouldn't spend time on this today.
My proposal would be for some brave soul (Michel?) to do a short note on how all GGF schema namespaces should look like and send it to the GGF Editor. (It doesn't have to be an formal document or anything, maybe an email would be ok.) I've seen this kind of discussion in more than one group and it would be nice to have some simple guideline.
I think that this is an excellent suggestion. It would be an excellent recommendation to have for all GGF groups.
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
We've discussed this sort of thing in the past and put it out of scope of version 1.0. (And I think that's where it should stay for now. I don't want to go down the path of adding just-one-more new feature at this moment.)
As Andreas and Donal have pointed out, and has been discussed at length at various stages of JSDL development, this is out of scope for JSDL1 - and will remain so if I could get my way :)
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)
I think we should have a post-v1 tracker and put these things there. (I can create a post-v1 tracker if the chairs agree.)
While I'm delighted that we are already thinking about starting on JSDL2, can we please get JSDL1 finished first (boy we've come a long way since 2.5 years ago!) :)) . Go ahead Andreas, why not create a post-v1 tracker now for a wish list. Cheers and take care, Ali
-- Andreas Savva Fujitsu Laboratories Ltd
-- ---------------------------------------------------- |epcc| - Ali Anjomshoaa EPCC, University of Edinburgh James Clerk Maxwell Building Mayfield Road E-mail: ali@epcc.ed.ac.uk Edinburgh EH9 3JZ Phone: + 44 (0) 131 651 3388 United Kingdom Fax: + 44 (0) 131 650 6555 -------------------------------------------------------------
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.
For Java application, JNLP (Java Network Launching Protocol) used by Webstart would be a good reference point for how to describe a java application. William On 8 Mar 2005, at 10:04, Donal K. Fellows wrote:
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.
--- William Lee @ London e-Science Centre, Imperial College London -- --- Software Coordinator --- A: Room 380, Department of Computing, Imperial College London, Huxley Building, South Kensington campus, London SW7 2AZ, UK E: wwhl@doc.ic.ac.uk | william@imageunion.com W: www.lesc.ic.ac.uk | www.imageunion.com P: +44(0)20 7594 8251 F: +44(0)20 7581 8024 --- Projects ---------------------------- GridSAM: http://www.lesc.ic.ac.uk/gridsam Markets: http://www.lesc.ic.ac.uk/markets ICENI: http://www.lesc.ic.ac.uk/iceni -----------------------------------------
participants (6)
-
Ali Anjomshoaa -
Andreas Savva -
Donal K. Fellows -
Karl Czajkowski -
Michel Drescher -
William Lee