OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [office] Another view on conformance?


I have no intention to defend places where features are underspecified and insufficiently defined for interoperabilty.  I do think we need to recognize that some aspects of ODF and its OpenFormula cannot be specified rigorously but only in practical terms.  Furthermore, drawing discretionary lines on variability can be very difficult.

The following analysis is about the reality of discretionary elements and how the specification might deal with them.

 - Dennis

SOME THOUGHTS:

Recently, I was reading an account that distinguished three kinds of conformance cases.

1. First, there are the SHALL and SHALL NOT cases.  That normative language is pretty clear.

2. Then there are the SHOULD, SHOULD NOT, MAY, and NEED NOT sort of optionality language.  (The use of CAN and CAN NOT is descriptive rather than prescriptive, and important to differentiate.)

Also, of course, there is the matter of defining what something is (as in the case of a named function that is expected to deliver [psuedo-]random numbers of some form).  But it could just as easily be the calculation of a well-known statistical or financial function that turns out not to be that precisely specified though widely used that becomes problematic when conformance needs to be addressed.

3. Finally, there are what are known as discretionary items.  Discretionary items are those things necessarily left to implementations (such as the maximum number of rows allowed in a spreadsheet, the arithmetic precision of numerical results and approximation of rational values, the actually-supported range of dates and times, the lengths of strings, the ranges of arguments to mathematical functions for which good quality results are provided, etc.)

One can have normative statements about these, in the form of minimums.  However, it might not be possible to agree on specified tolerances simply because the ranges of application are too great to be able to fix on an agreeable single weakest conformance.

With regard to random functions, there are two questions that come to mind for me: (1) "randomness" and its quality with respect to some expected purpose and (2) reproducibility.  It may well be that reproducibility is more important than having something like cryptographic quality in spreadsheet applications.   For example, can, given the same seed, an use of random functions lead to the same results in a reproducible and confirmable way?  This usually depends on the adoption of a specific algorithm for generation of the pseudo-random sequence and a specific means for specifying the seed.  (Of course, differences in automatic recalculation are going to reveal different results in the values used in different places, so this is not a strong assurance of reproducible spreadsheet computations).  Reproducibility is very important in testing and confirming that a spreadsheet is doing the right thing and also when the same spreadsheet is used with different implementations.  Only the designer of the sheet knows where it is important that the choice of random sequence be itself randomized (usually by choosing different seeds).  [That a designer may have made naive or careless assumptions about what the random-number function achieves is not something the specification can cure, of course.]

However, rather than fretting about having some perfect specification to adhere to, an implementer could simply stipulate some known and demonstrable properties of its implementation (periodicity, the algorithm, sources of technical information on its quality, etc.).  Also, the OpenFormula specification could specify that discretionary-implementation information that SHALL be made available in some usable form.  This may be far easier, and effective, than attempting to create a testable definition for what constitutes an acceptable random-number-generation sequence or in requiring a known algorithm (or some combination).  

It strikes me that the latter practical requirement might be far more successful and achievable than some sort of perfect, testable definition of the random-number function, the perfect achievement of which is in doubt.



-----Original Message-----
From: Dave Pawson [mailto:dave.pawson@gmail.com] 
http://lists.oasis-open.org/archives/office/200903/msg00000.html
Sent: Sunday, March 01, 2009 00:30
To: office@lists.oasis-open.org
Subject: Re: [office] Another view on conformance?

2009/2/28  <robert_weir@us.ibm.com>:
http://lists.oasis-open.org/archives/office/200902/msg00261.html
>> Weak definition, weak test. Your choice.
>>
>
> The point is not the definition of random.

It is, seems this is an example  what the TC won't accept.
The spec is weak, hence not verifiable.

Correct one, you'll address the other.


-- 
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]