REPOST: Topics for the upcoming phone conference
REPOST: Identical to the first attempt except the spec doc. The first mail seemed not to pass the ML software. Please obtain the JSDL specification document from Gridforge. ---------- SNIP ---------- SNIP ---------- SNIP ---------- SNIP ---------- Dear JSDL wranglers, this is a list of topics I would like to be decided on at the today's phone conference. (1) JobDefinition/@JSDLVersion attribute The version of the JSDP spec is uniquely defined elsewhere, and encoded in the namespace. I do not see any use of this attribute. (2) JobDefinition/JobIdentification/User/UserCredential The spec contains a comment that this element "... can be handdled through the standard extension mechanism." Let's decide on the phone conference to keep it or to drop it (and release it to the extension mechanism). (3) range values Karl and Stephen made a valuable proposal for a clear and efficient definition of range values: <lowerBound>xsd:integer</lowerBound> ? <upperBound>xsd:integer</upperBound> ? <exact>xsd:integer</exact> * <range> <lowerBound>xsd:integer</lowerBound> <upperBound>xsd:integer</upperBound> </range> * I propose to replace our current definition of a range value with this complex structure. (4) xsd:integer or xsd:double Partly touching topic 3, there's a discussion on wether to use integers or fraction numbers. I propose to use xsd:double together with an optional attribute "epsilon=xsd:double" for precision restrictions, changing the range type to <lowerBound epsilon="xsd:double"? >xsd:double</lowerBound> ? <upperBound epsilon="xsd:double"? >xsd:double</upperBound> ? <exact epsilon="xsd:double"? >xsd:double</exact> * <range> <lowerBound epsilon="xsd:double"? >xsd:double</lowerBound> <upperBound epsilon="xsd:double"? >xsd:double</upperBound> </range> * (5) (Non-)Critical extensions There's a discussion at the moment to tag particular elements of JSDL to be (non-)critical in terms of understandability and support, similar to the SOAP attribute "mustUnderstand=xsd:boolean". I propose to postpone this mechanism to after the first official JSDL release. (6) naming elements To promote reusage, elements of JSDL documents should be identifiable. An appropriate technique is using QNames. This requires the elements that we want to be reused to get a naming attribute of type xsd:NCName. I propose to use this technique to promote reusage. If we agree to use this, a follow-up action point will be assiged to identify the elements that need this new naming attribute and to propose a naming syntax. (7) Resource constraints global total and/or per process During GGF13, the issue came up that a resource can be defined to be total global or as per process. A use case may be to constrain a job to 10 Gigabytes of physical memory and at the same time to constrain the job's processes to consume no more than 10 Megabytes of physical memory. I propose to reflect this in JSDL expressis verbis rather to punt it out to an extension. If we agree on incorporating this, a follow-up action point will be the investigation and proposal of solution alternatives. (8) Comments and flames on the current specification document Although this is very short term, I attached the current latest version of the spec document - unofficial as I am not the official editor! - in which I tried to reflect all the changes we agreed on at GGF13. It was quite much, so expect to face errors in what I created. Cheers, Michel
Michel Drescher wrote:
(1) JobDefinition/@JSDLVersion attribute (2) JobDefinition/JobIdentification/User/UserCredential
No strong opinion on these.
(3) range values Karl and Stephen made a valuable proposal for a clear and efficient definition of range values: <lowerBound>xsd:integer</lowerBound> ? <upperBound>xsd:integer</upperBound> ? <exact>xsd:integer</exact> * <range> <lowerBound>xsd:integer</lowerBound> <upperBound>xsd:integer</upperBound> </range> * I propose to replace our current definition of a range value with this complex structure.
Good, except for the points in (4) below and I'm not sure whether that's the best order of elements (yeah, a very minor issue) and I think the element names <lowerBound> and <upperBound> are not very helpful at the top-level of the type (it's not at all clear to me what they mean just from looking at it, which is a bad sign). If we did <lowerBoundedRange> and <upperBoundedRange>, that'd be much clearer (i.e. it would indicate that the elements match ranges where one bound is either +Inf or -Inf respectively).
(4) xsd:integer or xsd:double Partly touching topic 3, there's a discussion on wether to use integers or fraction numbers. I propose to use xsd:double together with an optional attribute "epsilon=xsd:double" for precision restrictions, changing the range type to <lowerBound epsilon="xsd:double"? >xsd:double</lowerBound> ? <upperBound epsilon="xsd:double"? >xsd:double</upperBound> ? <exact epsilon="xsd:double"? >xsd:double</exact> * <range> <lowerBound epsilon="xsd:double"? >xsd:double</lowerBound> <upperBound epsilon="xsd:double"? >xsd:double</upperBound> </range> *
While I agree with xsd:double, I really don't like the epsilon attribute. Epsilons are just a mathematical hack to work around the fact that equality is a sensitive operation in any limited-precision floating-point system, and ut can always be encoded using different bounds (and substituting <exact> with <range>) though I don't really grasp the meaning of a range with bounds with an epsilon applied as well. Of more use would be an attribute to indicate whether ranges are evaluated using <= or < operators (i.e. whether the interval is closed or open) since that's difficult to correctly express with ranges. Using the attribute name discussed by Karl and myself on the list and attempting to consolidate everything else: <jsdl:upperBoundedRange jsdl:exclusiveBound="xsd:boolean"? > xsd:double </jsdl:upperBoundedRange> ? <jsdl:lowerBoundedRange jsdl:exclusiveBound="xsd:boolean"? > xsd:double </jsdl:lowerBoundedRange> ? <jsdl:exact> xsd:double </jsdl:exact> * <jsdl:range> <jsdl:lowerBound jsdl:exclusiveBound="xsd:boolean"? > xsd:double </jsdl:lowerBound> <jsdl:upperBound jsdl:exclusiveBound="xsd:boolean"? > xsd:double </jsdl:upperBound> </jsdl:range> * The default value of all jsdl:exclusiveBound attributes is always "false" indicating that <= (or =>) is the comparison operator to use. If we are going to insist on having jsdl:epsilon attributes (and I don't think we should) they should only ever go on <jsdl:exact> elements. Bear in mind that there is a significant set of set of integers that is actually expressible exactly in xsd:double, including virtually all the useful range of xsd:long (effectively giving 55-bit ints).
(5) (Non-)Critical extensions I propose to postpone this mechanism to after the first official JSDL release.
Agreed. JSDL will be useful without and I think we can punt it.
(6) naming elements
Sounds good.
(7) Resource constraints global total and/or per process
No strong opinion on this. Donal.
participants (2)
-
Donal K. Fellows -
Michel Drescher