[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Agenda Request: Implementation-defined, Unspecified, and Undefined behaviors in OpenFormula
Rob, I notice in reviewing JIRA issues that there are many places where (1) implementation-defined is important in being able to say something definitive about an ODF feature; and, (2) implementation-defined is very valuable in sorting out the relationship of a feature to the different conformance classes. PROPOSAL: That we introduce the implementation-defined condition in the conformance section of all parts of the ODF specification. I request that we discuss this on the next available agenda (06-29 or 07-06). - Dennis PS: I don't think declarative is as passive (done as comments) as David Wheeler remarked. It seems to me that such declarative information is about what is required to be supported for the document to be consumed properly. It could be ignored, of course, but there is the opportunity for an implementation to indicate that it cannot honor the declarative requirements and also obtain agreement to do what it is able to do, if it has a fallback. Some declarative requirements around discretionary provisions (size of a table's "used area" for example) might actually be ones that an implementation, in checking them, might end up declining to process because there is no reasonable fall-back in the implementation. The request for agenda discussion is with regard to whether the TC considers it worthwhile to introduce an implementation-defined condition on required documentation. We certainly need it, either way, to characterize certain features in a clear way. -----Original Message----- From: robert_weir@us.ibm.com [mailto:robert_weir@us.ibm.com] Sent: Friday, June 12, 2009 09:55 To: office-formula@lists.oasis-open.org Subject: Re: [office-formula] Implementation-defined, Unspecified, and Undefined behaviors in OpenFormula "David A. Wheeler" <dwheeler@dwheeler.com> wrote on 06/12/2009 12:25:54 PM: > > robert_weir@us.ibm.com wrote: > > Would it be worth taking a declarative approach on some of these? > > I doubt it, but I'd like to know what others think. > > I believe the goal is NOT to have zero implementation-defined items. I > believe, and I suspect you agree, that the goal is interoperability. If > some decision doesn't harm interoperability in real life, then having it > implementation-defined is a non-issue. In fact, prematurely specifying > something where there is disagreement can make things worse. > Maybe I wasn't clear enough. Implementation-defined means behaviors can vary, but implementations must document what they do, in written documentation that accompanies the software. That is the typical definition. A declarative approach means that implementation behavior can still vary, but instead of documenting this behavior only in written documentation, the behavior is documented in the XML itself. This would apply in specific cases where there are only a small choice of allowed behaviors, such as 0^0, whether boolean and number are distinct, SUM(), etc. We're not mandating specification evaluation behavior, but mandating that the behavior used by the application that writes the document be declared in the document's XML. so something like: of:distinct-boolean-type=true or of:empty-sum-result="error" In any case, my experience with spreadsheets is that "real life" can be quite weird at times. Take the zero-parameter SUM() for example. The zero result can be quote innocuous in sum. So a sum-of-sums would work fine even if someone might have an empty SUM() someplace. This might be an error from the business logic perspective. The spreadsheet might not be calculating what the user wants it to be calculating. But this is user error and we can't outlaw that. On the other hand, they author might well aware of this, and it might be a complicated result of indirect addressing, interaction with macro automation, etc., that leads to an innocuous use of an empty SUM(). Now take that sheet, whether manually created or created via macro automation, and send it to another user, with a different editor. Their empty SUM() no returns an error, which percolates erros all through the sheet. If the original sheet was created via automation, the offending formula might be on a hidden sheet or row, maybe even protected with a password. In any case, they are going to be totally confused as to why their document is totally screwed up. So even little things matter here. In particular, edge functionality with SUM() -- one of the most commonly used functions -- is going to show up far more often than edge cases of BIN2HEX(). So we might prioritize our efforts around reducing implementation-defined functionality in the most-used functions. -Rob --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]