Hi Donal, all, Please read my responses below to the issues raised and let me know your thoughts. I appear to have adopted a bit of a one-track approach recently but I think it's appropriate! Donal K. Fellows wrote:
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.
I think that this issue is another implementation concern for which we should only provide recommendations in the specification, and agree that this should not affect the schema (nor lead us to consider mandating a particular language).
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.
For this issue I'm again (perhaps unsurprisingly! :) ) convinced that it is an implementation concern. An XML parser/validator will naturally be expected to validate that a JSDL XML document conforms to the defined schema, e.g. ensure specified values are of type xsd:decimal, xsd:double, etc.. Beyond that though, in terms of subsequent processing, I very much think that we should only provide recommendations where appropriate. Even if we specified formats we cannot mandate underlying implementations to use them. Using the example above I personally would only anticipate recommending format consistency when specifying looping.
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.
Once more I feel we should only recommend to implementors that they may wish to make such calculations.
Donal. -- jsdl-wg mailing list jsdl-wg@ogf.org http://www.ogf.org/mailman/listinfo/jsdl-wg
Thanks, gef