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

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-formula message

[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]