Summary 2010-08-24 of OpenFormula meeting

[Eike Rathke <eike.rathke@oracle.com>]

Hi,

Again, on behalf of David Wheeler.

  Eike

----- Forwarded message from "David A. Wheeler" <dwheeler@dwheeler.com> -----

Date: Tue, 24 Aug 2010 12:21:34 -0400 (EDT)

=================


Summary 2010-08-24 of OpenFormula meeting

(As always, please reply-all with corrections.)

Attendees:
David A. Wheeler
Andreas G.
Eric Patterson
Patrick D.
Eike Rathke
Dennis Hamilton


Not present (and usually present):
Rob Weir


Note: For our current status, see the dashboard:
http://tools.oasis-open.org/issues/secure/Dashboard.jspa?selectPageId=10056


NOTE:
We will skip next week (Aug 31) because at least two people will be at an
ODF-related conference.  We will meet two weeks from today (Sep. 7).


TOPICS:

As usual, we focused on unassigned & NEEDS-DISCUSSION JIRA items.

* OFFICE-3039: Assign to Wheeler

* OFFICE-3323 & OFFICE-3325 (HOST-REFERENCE-RESOLVER)
Dennis Hamilton will pick it up, since he proposed it.

* OFFICE-3354 (Public Comment: Comment on ODF 1.2 OpenFormula (6.17 Rounding Functions))
Eike will pick up - believe it's a dup

* OFFICE-3357 ("Public Comment: Comment about PV")
This needs to be resolved for CD06.
Wheeler assigned to Rob Weir because Rob is already working other PV issues.
If Rob objects, we can revisit.

* OFFICE-3342 (NEEDS-DISCUSSION: ODF 1.2 Part 1 "IRI" abuse)
It's not clear it matters *here*, because they are relative references.
If IRI references can be relative, somebody has to say something.
Dennis: If it's a non-scheme relative IRI, it'll be relative to the package per part 3
unless it reaches out of the package (e.g., via "..").
This depends on the IRI discussion of part 1, then we need to be compatible (maybe).

We might not have to say anything here, we just don't know yet.

We just need to leave this open until IRIs are resolved in part 1.

* OFFICE-3042
http://tools.oasis-open.org/issues/browse/OFFICE-3042
The big discussion issue was this proposal:
"5.7.1 Future OpenFormula Functions
Open Formula functions defined after this version of the specification should
include a "_OFFN" prefix followed by a period and the original function name itself."

Basically, the system should know "where did this function name come from?"
* Misspelling
* Future
* User-defined

: Don't confuse what's shown in the user interface with what's in the file.
If you open an ODF file, and there's no prefix, it must be an ODF function.
What you show to the user is a different story.

Eric P.: The problem is that current systems will save function names that are user-defined, etc.,
without a prefix, so it's not clear what the function's source is.
Excel lets people enter nonstandard names, which always return #NAME?.
Perhaps there will be a user-defined function that will be available.
At that point it's not clear to the application what the user's intent is.
Problem is, we don't know user's intent.

Andreas: No matter what you write, it may be "wrong" because if it's an unknown function
to the application you don't know what the user's intent is.

Andreas: An application should never write an unprefixed function name if it's unknown.

Wheeler: Could you add "UNKNOWN." prefix if unknown?

?: Could spell "_OFFN." differently.

Eric: I'll leave out prefix & withdraw it, and just focus on "USER.".

Wheeler: Okay.

* OFFICE-3029
http://tools.oasis-open.org/issues/browse/OFFICE-3029

We discussed this yesterday in the TC call.

What about is-true-formula(...)?

?: How do we reference the current cell?

Eric: In Excel, the content validation is done when you try to change its value.
We temporarily set its value, if the validation works out, then that's accepted,
otherwise it's reversed & error shown.

Eike Rathke: OOo does it differently; we check just the value itself.
We presume the *original* values are valid, and only check changes.

There's a table-base-cell address that accompanies this, so it provides the information.

Dennis Hamilton: We need to specify *when* validation happens in part 1.

Wheeler: We could say that while being read in, a consumer can assume that all values meet their validation criteria.

Patrick: We could say that a valid ODF document meets all its validation criteria

: So a conformant producer wouldn't produce something doesn't meet.

Eric: No, it's only for when inputting data.  The validation rules may change based on other values.

Dennis: Can a writer produce a document that doesn't meet the validation rules?

Eric: Yes.  Think of it as an input mask for a cell that gives guidance for expected values of the cell.

Dennis: So we need to say this is *guidance*.

Eike: We only mention this is section 19.623; that's the context.

Dennis: We need to fix 9.4.4.  The validation is for use in a UI, and NOT validation for table cells.
The fix needs to be in part 1.

Eric: I think the confusion is with the term "validation"; that's the term we use in Excel.
But you're implying that involves validation with markup.  We use this to store a "validation rule";
we don't say much about its purpose and rule.

Dennis: We should be clear what it is, that is, it is not enforcing a rule.
"Bold" stays in document even if it's not displayed.

Wheeler: I think this works syntactically - all agree?

Eric: I agree, can parse.

Wheeler: Documents can be written where some values do not meet this condition.
This condition is used when changing values in UI, for checking them before accepting them.
The trick will be writing this text more clearly, so that this is understood by spec readers.


Eike & Rob cannot meet next week.


--- David A. Wheeler 

----- End forwarded message -----

-- 
Automatic string conversions considered dangerous. They are the GOTO statements
of spreadsheets.  --Robert Weir on the OpenDocument formula subcommittee's list.

PGP signature