This is a follow-up to a discussion had on the recent JSDL call w.r.t. the LoopDouble comments from the parameter sweep public comment period. As I see it, there are two key challenges with LoopDouble (above and beyond those of LoopInteger): 1) Accuracy of computed values 2) Format of computed values (this wasn't discussed; I only thought of it since) The first is an issue because it can lead to a different number of iteration steps, and it stems primarily from the fact that decimal fractions are not all exactly representable in binary arithmetic. The way to fix this is to compute the number of steps to use (probably by dividing the range by the step and rounding appropriately) and to then use integer iteration behind the scenes with an appropriate (trivial) function to convert to the floating-point values. The advantage of doing this is that it does not require the use of fancy things like decimal arithmetic packages, which are not at all universally available; while Java might have one, I'd hate to have to mandate the use of Java to process JSDL documents! IEEE double precision binary floating point arithmetic is much more common (i.e. virtually universal in hardware now). In other words, this can be fixed without schema changes. Of more of an issue is the fact that LoopDouble does not specify how to format the numbers. That is, when it wants to generate the number half way between 0.0 and 1.0, should it actually generate the string 0.5 or 0.50 or 0.500 or 5e-1 or 500e-3 or ...? You can't use the format of the arguments since XML processors that map to an object model based on the infoset won't retain the format used but will instead focus on the logical value. (And anyway, the formats could also be inconsistent...) Either we need to specify something that is "good enough" for most uses (e.g. "a maximum of 14 significant figures, but with pointless trailing zeroes stripped so long as there is at least one digit after the decimal point; no use of scientific notation") or we need to change the schema to provide control. Looking through the Stephen's public comment, I see that he's worried about Exception values. They're not actually an issue because we know what the step is and can therefore calculate a sensible epsilon for the "equality" test (e.g. 1% of the magnitude of the step). Perhaps the spec should make some mention of this to make implementors aware of the subtleties involved. Donal.