|
[
Permalink
| « Hide
]
Patrick Durusau added a comment - 06/Jul/09 01:19 PM
Good question and I don't know the answer. The <table:calculation-settings> element has this and other attributes that control the application of the algorithm but I don't know where the algorithm is stored.
discussed in ad-hoc on 7/7 -- Eike will propose resolution.
The setting influences string queries that compare cell content against a text search criteria (pattern). If the value of table:search-criteria-must-apply-to-whole-cell is "true", the search pattern must match the entire cell content; if the attribute's value is "false", the search pattern can match a substring at any position within the cell.
The setting is used with the <table:filter-condition> element if the table:data-type attribute has the value "text" and the table:operator attribute is one of match (matches) !match (does not match) = (Equal to) != (Not equal to) Furthermore, the following spreadsheet functions use search criteria: DAVERAGE DCOUNT DCOUNTA DGET DMAX DMIN DPRODUCT DSTDEV DSTDEVP DSUM DVAR DVARP COUNTIF SUMIF LOOKUP VLOOKUP HLOOKUP MATCH Thanks!
So, is the "pattern" stored in the file or supplied by the implementation, subject to the settings you mention? Possible text: The table:search-criteria-must-apply-to-whole-cell attribute specifies the matching criteria for search patterns against cell content. The defined values of the table:search-criteria-must-apply-to-whole-cell are: false: a search pattern can match any substring at any position in a cell. true: a search pattern must match the entire content of a cell. The table:search-criteria-must-apply-to-whole-cell attribute appears on a <table:filter-condition> element if the table:data-type attribute on that <table:filter-condition> element has a table:data-type attribute with the value of "text" and a table:operator attribute with a value of: match (matches), !match (does not match), = Equals, and, !=Equals (Not equal to). **** Question: Is the table:data-type attribute value of "text" and the table:operator value of match (matches), !match (does not match), = Equals, and, !=Equals (Not equal to) restrictions on the presence of table:search-criteria-must-apply-to-whole-cell? In other words, if either or both of those attributes don't have the required values, is the presence of table:search-criteria-must-apply-to-whole-cell prohibited or is it ignored? This item deals with a perceived defect with respect to 1.0, so the functions listed are not defined and we can't refer to them here.
For match and !match the "table:value attribute contains the regular expression that the table cells have to match or must not match". We probably should state in 8.7.4 that these regular expressions are modified by that setting. (I don't understand why not the correct regular expression is used anyways rather than having this extraneous caclulation setting.) Since the calculation setting is document wide that setting applies to equal and not equal, does that mean that we cann't ever test for true equality if the setting is FALSE? discussed 7/13, recommended that 8.7.4 cross-reference table settings element. Also should clarify the run-time model in ODF 1.2.
@Patrick:
> So, is the "pattern" stored in the file or supplied by the implementation, subject to the settings you mention? How the pattern is evaluated (the match determined) is subject to this setting, yes. Regarding "specifies the matching criteria" of the text I would propose "specifies a matching criteria" instead, there might be others as well. Regarding your question: the table:search-criteria-must-apply-to-whole-cell is an attribute of the <table:calculation-settings> element and as such can never be prohibited. In the context of table:data-type not being "text" or table:operator not being one of =,!=,match,!match the setting is ignored. @Andreas: > We probably should state in 8.7.4 that these regular expressions are modified by that setting. (I don't understand why not the correct regular expression is used anyways rather than having this extraneous caclulation setting. The setting is also in effect if table:use-regular-expressions="false", the search pattern would not be a regular expression. @Rob:
I don't understand your "recommended that 8.7.4 cross-reference table settings element" comment. Additional note: if an issue is targeted to two versions of the standard it would make sense to mention which version when referring section numbers.. here it was ODF 1.0 So, for ODF 1.0 Errata 02 this issue would have a different resolution than for ODF 1.2, if any. @Eike:
I understand that the search pattern may not be a regular expression, but having a global setting for such things as "criteria applies to whole cell" seems to be pretty bad design: Suppose I have two filters, one uses "match" and is supposed to not apply to the whole cell, and the second one uses equal and is supposed to apply to the whole cell. It seems to me that I can't save this situation in an ODF spreadsheet file. @Andreas:
Setting table:search-criteria-must-apply-to-whole-cell="true" and using an appropriate regex pattern (e.g. leading and trailing ".*") would do in that case. In ODF 1.2 we additionally have table:operator begins (begins with) contains (contains) !contains (does not contain) ends (ends with) !begins (does not begin with) !ends (does not end with) that would allow the different cases for non-regex patterns and distinguish from '=','!=' if table:search-criteria-must-apply-to-whole-cell="true". @Eike:
So in other words, in 1.2 there is no need for this calculation setting? For ODF 1.2 the resolution may be different because we have a formula specification where.
I suggest we use this task for ODF 1.0 only, and I don't see the response shown in ODF 1.0 Errata CD04 anywhere here.
1. In Errata CD04, the section reference should be to 8.5.2. The sub-heading "Search Criteria Must Apply to Whole Cell" is correct. 2. The wording of the description for table:search-criteria-must-apply-to-whole-cell applies only when table:use-regular-expression="true", as opposed to it applying differently depending on the table:use-regular-expression value. The rewording in Errat CD04 removes that peculiarity, but I wonder if it thereby becomes more than an errata in so doing? In particular, it is not clear whether table:use-regular-expressions="true" will over-ride this setting whenever a regular-expression case applies. 3. Another concern I have is that I have never, in my own experience seen a situation where the absence of whole-cell comparison was any-substring-comparison for matching strings. In most of my experience, the question is whether or not a leading substring would match. I wonder whether this more-rigorous, and quite regex-unrelated restatement is too substantive. The use of "search-pattern" in the restatement is also puzzling. 4. I propose this be one of those cases to be left implementation-dependent until clarified by ODF 1.2. [Changed 2010-03-27 to say implementation-dependent, not implementation-defined.] @Dennis,
let me reply to the the four parts of your comment: Regarding your comment #1: Fixed this, thanks good catch! Regarding your comment #2: I have problems to follow your interpretation that the wording is dependent on table:use-regular-expression="true". Do we agree that the value of @table:search-criteria-must-apply-to-whole-cell influence the outcome of regular expressions and not the other way around? In any case, if there is room for misunderstanding the text of the resolution should have fixed it. Regarding your comment #3: Do you have wording suggestion here, Dennis? Regarding your comment #4: As the reasoning is missing within this comment, I believe was related to #2. Dennis, if you have further objections in regard of the resolution, please provide a wording I could resuse and we might base our discussion on. Thanks, Svante I still believe this is is confused.
There is no regular expression implicit in <table:filter-condition>. When regular expressions are not being used for comparisons, how does this make sense? When regular expressions are being used as part of a comparison/match condition (however that is intended to be expressed), it is not clear why the regular expression is not sufficient by itself. I assume that regular expression matching always begins at the beginning of the subject field, and the only question is whether or not it can quit early. But a greedy regular expression can always be written to do the job without depending on this attribute at all. I.e., if a regular expression is being used, there is no need for this attribute. It is only with comparisons that do not employ regular expressions where this attribute is useful. In this case, I question why one would match anywhere as opposed to match the beginning on false. If you tell me that is really what happens in the dominant implementation(s), I will be surprised, but I will not object. But we should not make this provision unless it is really true in practice. In the resolution for 8.5.2, the "Note:" is stricken, since this would be appropriate only if the information were obtainable without it. In the remaining Note text, "has the value of text" is adjusted to be "has the value text" (where text is in attribute-value font style). This adjustment appears in CD04-rev07.
[Note: the file OpenDocument-v1.0-os+errata-cd04r7-2010-07-28.odt/.pdf has the errata item applied incorrectly. The text of CD04-rev07 matches the adjusted resolution however.] Errata 02 - ODF 1.2 Reconciliation seems to be accomplished in the wording of 19.709 as of OpenDocument-v1.2-cd05-part1-editor-revision_05.odt.
There is an ambiguity with the regard to the entire content of a cell, but this may be alleviated by the connection of the attribute to <table:filter-condition> table:data-type (or not). That was not addressed in Errata 02, however. In some respects, the more-precise ODF 1.2 treatment suggests that the Errata 02 fix is incorrect. We may need to address that when moving to ODF 1.1 Errata. |
|||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Applied
Major
ISO/IEC JTC 1/SC 34 N 1078 : DEFECT REPORT NUMBER JP2-20