[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-formula] TC review comments, hiding test cases (remove from formal spec)
Hi David, On Friday, 2007-05-11 00:55:42 -0400, David A. Wheeler wrote: > 1. Test cases. > So even though I think this is > NOT a good idea, I think we must NOT include the test cases in the > official spec so the spec can be accepted. Seconded. That was my impression almost from the beginning when I heard that ISO committees most certainly can not be convinced to accept normative test cases. > Instead, they should be in > hidden text along with the other commentary. See below. > We might include 1-2 > examples in each, which would help slightly. A few examples are always good. For most functions, taking 1-2 test cases and convert them to examples will do. > This change will require > some rewriting of text since what was unambiguous before might become > ambiguous. Regarding the rewriting I have a request: could someone else take on the work? Reason is I'm more busy with implementation now, and also want to start implementation of our formula spec of course. Robert, could you take that task? I will continue to contribute some missing pieces to the spec, and also do some necessary review, but can't spend almost my whole time on it like I previously did. > 2. Hiding Commentary > > The first page clearly states that the notes, etc., will not be in the > specification, but many reviewers just want to see what the FINAL spec > will look like, and DON'T want to see all the rationale for why it is > the way it is. So we need to hide the other commentary, and turn on > hiding by default. Those who want to see the commentary can just turn > it back on. I don't think that this hidden text approach will be sufficient. For OASIS we will have to deliver the final standard document in several formats and for this would have to produce some interim document anyway. I don't know what formats ISO accepts. So IMHO the best would be to continue work on our master document and bring it into a shape where we easily can generate a version without annotated notes and test cases to produce the final spec document. The annotated version will always be available, and all editing will take place on that master document, from which we can generate versions as we need. I also don't see a problem with "someone not in the know might be tempted to edit a generated document instead of the original one". After all, this subcommittee or the TC will be in charge of doing all modifications to the spec, and we should know how to work on it. Or am I missing something? > 3. Basis/YEARFRAC definition > > We need to define the Basis/YEARFRAC stuff more exactly (esp. with the > test cases removed). This is a specific technical comment which > I agree with. I agree. Even with the test cases the functionality isn't very clear, we should give the formulas / algorithms to be found in the ISDA document we mentioned in the notes. As that isn't a standards document but only conventions, simply referring it probably isn't enough. Eike -- Automatic string conversions considered dangerous. They are the GOTO statements of spreadsheets. --Robert Weir on the OpenDocument formula subcommittee's list.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]