OASIS Open Document Format for Office Applications (OpenDocument) TC

Expand all | Collapse all

Another view on conformance?

Rob Weir

Rob Weir02-28-2009 15:26

David Pawson

David Pawson02-28-2009 15:35

Rob Weir

Rob Weir02-28-2009 16:14

David Pawson

David Pawson02-28-2009 17:01

  • 1.  Another view on conformance?

    Posted 02-28-2009 07:59
    http://tr.im/gRUC
    
    Rick Jelliffe on Conformance, with a view on ODF.
    including:
    
    
    
    
    regards
    
    -- 
    Dave Pawson
    XSLT XSL-FO FAQ.
    Docbook FAQ.
    http://www.dpawson.co.uk
    


  • 2.  Re: [office] Another view on conformance?

    Posted 02-28-2009 15:26
    Dave Pawson 


  • 3.  Re: [office] Another view on conformance?

    Posted 02-28-2009 15:35
    Usual ducking and diving Rob?
    
    2009/2/28  


  • 4.  Re: [office] Another view on conformance?

    Posted 02-28-2009 16:14
    Dave Pawson 


  • 5.  Re: [office] Another view on conformance?

    Posted 02-28-2009 17:01
    2009/2/28  


  • 6.  Re: [office] Another view on conformance?

    Posted 02-28-2009 21:31
    Dave Pawson 


  • 7.  Re: [office] Another view on conformance?

    Posted 03-01-2009 08:30
    2009/2/28  


  • 8.  RE: [office] Another view on conformance?

    Posted 03-01-2009 17:26
    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.