[jsdl-wg] REPOST: Topics for the upcoming phone conference

[Donal K. Fellows]

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.