|
Proposal: "The table:condition attribute specifies the condition that must evaluate to "true" for all cells the validation rule is applied to. The value of this attribute should be a namespace prefix, followed by an implementation-defined Boolean expression.
Then delete "A typical syntax..." and following. We should also check to see if we're using "namespace prefix" uniformly when referring to attribute values. However, in ODF 1.2, we should consider fully specifying this syntax. A proposal for specifying the syntax is:
-- The defined conditions are: - cell-content-text-length() op value, where op is one of the relational operators '<', '>', '<=', '>=', '=' or '!=': true if the length of the cell's text compared to the value specified in the condition by value using the relational operator op evaluates to true. - cell-content-text-length-is-between(value1, value2): true if the length of the cell's text is between value1 and value2. - cell-content-text-length-is-not-between(value1, value2): true if the length of the cell's text is not between value1 and value2. - cell-content-is-in-list(list), where list is one or more string entries, separated by ';', or a formula: true if the cell's content is in list. -cell-content-is-decimal-number() and condition, where condition is one of the value conditions below: true if the cell has a numeric value and condition is true. - cell-content-is-whole-number() and condition, where condition is one of the value conditions below: true if the cell's cell has a whole value and condition is true. - cell-content-is-date() and condition, where condition is one of the value conditions below: true if the cell has a date value and condition is true. - cell-content-is-time() and condition, where condition is one of the value conditions below: true if the cell has a time value and condition is true. The defined value conditions are: - cell-content() op value, where op is one of the relational operators '<', '>', '<=', '>=', '=' or '!=': true if the cell's value compared to the value specified in the condition by value using the relational operator op evaluates to true. - cell-content-is-between(value1, value2): true if the cell's value is between value1 and value2. - cell-content-is-not-between(value1, value2): true if the cell's value is not between value1 and value2. The defined variables are: - value , value1 and value2 are a numberValue, a string or a formula. - numberValue is a whole or decimal number. The number shall not contain comma separators for numbers of 1000 or greater. - string comprises one or more characters surrounded by quotation marks. - formula is a formula (see 18.644) without the equals (=) sign at the beginning. --- A detail that is not yet covered by this proposal is whether the individual formulas or the expression itself shall have an (possible optional) namespace prefix. The description of the syntax is similar to what we have for style:condition. Just noticed that we in ODF 1.1 have already specified that the expression itself should have a namespace prefix. We would therefore keep that. But we should add a sentence what the meaning of the namesace prefix is:
The namespace prefix specifies the syntax and semantics used for formulas that are contained in the condition.. Though we did not have that in ODF 1.1, we should also add an (maybe optional) namespace prefix for style:condition.
Correction will appear in OpenDocument-v1.2-part-1-cd03-rev05.
1. There is no account here for the errata that was actually produced in ODF 1.0 Errata CD04.
2. The instructions to delete material is incomplete. All text from "A typical syntax" down to the beginning of the schema fragment should be deleted. 3. It makes no sense to say there is a namespace prefix followed by an implementation-dependent Boolean expression. Since a namespace prefix is required, it is perfectly safe to say what the namespace accomplishes. I would say that the absence of a namespace prefix has implementation-dependent interpretation. 4. QUESTION: Since, formally, the separating colon is not part of the namespace prefix according to [xml-names], can we go so far as to say that there is a colon followed by a Boolean expression whose syntax and semantics is specified under the namespace bound to the prefix? @Dennis:
Let me reply to the the four parts of your comment: Regarding your comment #1: Although contained in ODF 1.0 Errata CD04, the resolution of the JIRA issue was not updated. Fixed this now. Regarding your comment #2: The deleted material in the resolution of the errata (and now as well in the JIRA resolution) goes even further as you suggested. Regarding your comment #3: The prefix is used to easily identify implementation-dependent expressions and give a collection/bundling mechanism. It is not a mandatory requirement and should be kept as best practise. Regarding your comment #4: If I understand correctly, you ask if the spec can require from a vendor to specify their expression at the URL given by the namespace? Although your idea would be indeed the best practise approach, the idea would no longer align with 'implementation-dependent', but would be a specialiazation of 'implementation-defined', requiring a documentation. This would work for an errata, as existing implementation might suddenly no longer support ODF due to the lack of documentation. I agree that use of a namespace prefix that is not otherwise defined is certainly implementation-dependent - we say that the namespace binding determines the syntax and semantics, however that is known.. However, we have not felt the need to say so elsewhere where we state the same provision.
However, since we say that there *should* be a prefix, but one is not required, it seems fair to make explicit that the interpretation in the absence of a namespace is definitely implementation-dependent. I don't mind that we make more than that implementation-dependent, but it has not been the practice when a namespace prefix is supplied. Errata 02 - ODF 1.2 Reconciliation. The table:condition attribute has been made far more specific in ODF 1.2 and the defect that the Errata 02 item is defined to resolve is certainly reconciled.
|
|||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Applied
Major
ISO/IEC JTC 1/SC 34 N 1078 : DEFECT REPORT NUMBER JP2-21
Correction: This is not a grammar in any formal sense, just valid conditions (yes, it needs to be a formal grammar)