Re: [office-formula] Summary 2010-08-24 of OpenFormula meeting

[Mary McRae <mary.mcrae@oasis-open.org>]

Why is David unable to post?

Mary

On Aug 25, 2010, at 7:21 AM, Eike Rathke wrote:

> 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.