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.