[jsdl-wg] range value type

[Donal K. Fellows]

Karl Czajkowski wrote:
> It is very straightforward in terms of writing XSD.  With some changes
> I recommend, it would look like this as a sequence:
>   <...>
>      <lowerBound>xsd:integer</lowerBound> ?
>      <upperBound>xsd:integer</upperBound> ?
>      <exact>xsd:integer</exact> *
>      <range>
>         <lowerBound>xsd:integer</lowerBound>
>         <upperBound>xsd:integer</upperBound>
>      </range> *
>   </...>

Looks mostly good, except we should use xsd:nonNegativeInteger or
xsd:double instead of xsd:integer. I can't currently think of a use case
for negative bounds, but there might be a case to be made for allowing
floating-point representations. (They become more useful when you start
using extension resources, perhaps because they are modelling some
scientific instrument, and we want to encourage the reuse of our types
so that they can be tooled just once.)

Your semantics section is exactly right IMO, modulo the exclusiveBound
attribute discussion (which mostly just expands it out with lots of
minor variations).

> We had discussed using xsd:integer and this implies that any use of
> this type must just define the "base" units that are being counted.
> The only problem in our base terms is (cpu-)time, where I wonder if we
> are better off using a floating-point type to allow the base units to
> be seconds and still allow fractional second specification.  Choosing
> some specoific fractional second as the base unit seems unappealing to
> me.
> 
> If we provide a floating point/fractional version, I think there needs
> to be an optional attribute on the exact element to specify a
> precision or epsilon value for equality tests, e.g.
>    <exact jsdl:precision="0.001">3.1415927...</exact>

Actually, the correct thing to do is for the caller to always use
bounded intervals with floats unless they really know exactly what they
are after, since some floats (e.g. 1.25) actually exactly representable
in IEEE arithmetic. OK, it's punting the problem to the document creator
(the JSDL processor just checks what it is told) but that's the right
thing to do in my experience with processing floats.

> Perhaps a simpler solution is to stick with arbitrary length integers
> and add an optional divisor attribute that defaults to 1:
>    <exact jsdl:divisor="100000">314159</exact>

Ick. That really makes handling floats much nastier! There's no need to
do this; xsd:double will be handled right (and tooled nicely) as long as
callers don't have unrealistic expectations of float math. (OK, many
people do have those unrealistic expectations, but that's not our fault
and we can't fix the world.)

> Also, I suggest that we place an optional attribute in the boundary
> elements:
>    jsdl:exclusiveBound=xsd:boolean
> with default false, meaning that by default the range of acceptable
> values includes the boundary value in the element body.  Setting it to
> true would mean that the boundary value is not part of the range.
> This supports any meaning captured before in the operator enumeration,
> I think.

I have absolutely no objection to adding this to UpperBound and
LowerBound, and it makes working with real-like numbers much easier
(there are some subtleties in there to do with the difference between
open and closed interval bounds.)

> A minor note is that the elements have to appear in the sequence
> order, which I argue is a good thing for machine-machine communication
> as the parse tree will yield three monomorphic arrays of values with
> clear meanings, rather than one polymorphic array that the consumer
> has to traverse.

I'm not sure I'd enforce that, but as we don't need to define an
algorithm for minimization or testing equivalence of range types, I'd
just not bother. Say that doing it is recommended, not required. :^)

Donal.