|
[
Permalink
| « Hide
]
Patrick Durusau added a comment - 06/Jul/09 01:06 PM
We have been inconsistent in our usage. I suggest the TC choose data type and I will sweep the draft for all instances. That does leave us with "value-type" in attribute names but there isn't anything I can do about that now.
On re-reading this I think I see what Makoto means. We called these "value types" in the prose and then proceeded to refer to them as data types. Ok, that is inconsistent, even though data type is more correct. Will correct to be consistent in this version but 1.2 should still follow the correct usage.
I think that we should reconsider this and also keep 1.2 consistent with 1.0, not vice versa.
Based on the typography, it is clear that these sections are making reference to the value of the office:value-type attribute. It would be more appropriate to say, for "Cell Current Currency" under 8.1.3 that "This attribute is only evaluated for cells whose <tt>office:value-type</tt> value is <tt>currency</tt>." The same rewording is applicable in the additional subsections of 8.1.3 where the use of "data type" is inapplicable. The schema establishes a complex relationship between the different cases of office:value-type values and the other attributes which can be present. For example, for the three "numeric" office:value-type attribute values float, percentage, and currency, the office:value attribute must be present and the data type of its value is double. So value type and data type do not correspond at all. RECOMMENDATIONS 1. Make the change to refer to the "office:value-type value" in all of the places that are changed to mention "value type". 2. Make the same change in the preceding 8.1.3 "Cell Current Numeric Value" where the problem also exists, even though it was not specifically called out in the defect report. It is clearly part of the defect and the same correction is called for. ADDITIONAL 3. Consider whether the form of expression that "This attribute is only evaluated when ..." makes any sense. Under the schema, the attribute is only allowed to be present under those conditions. Also, there is no attribute tableoffice:currency as mentioned in the 8.1.3 subsection "Cell Current Currency." It is office:currency, and office:currency is optional when the office:value-type value is "currency". Note further that office:currency does not hold the value (the value is carried in the office:value attribute that is required by the office:value-type="currency" case). office:currency holds a code that determines what the currency system is (USD, GBP, EUR, etc.). Re-opened to resolve confusion between data type and the dependency on the values of the office:value-type attribute and the additional attributes that can occur depending on the office:value-type value.
I note that ODF 1.2 Part 1 CD04 section 19.387 on office:value-type does a better job of making these distinctions clear, although it could be tightened a little.
Dennis, I did the following:
1) Expanded the fix to the previous sub-chapter 2) Included the fix of the wrong spelled attribute name 3) Adapted different font usage for the value type What I did not was: 4) Changed the wording of "only evaluated" as it specifies what the application does, ignoring the invalid ODF and make easy to read. I share your feelings that ODF 1.2 has an improved wording, but would like to keep the fix for the errata only to the necessary, keeping it simple. Nevertheless thanks for the good review, spotting the above topics, we had overseen! Svante I disagree with regard to the "only evaluated." According to the schema, those attributes are only permitted when the particular office:value-type attribute is present. It is invalid for the particular attribute to occur any other time. Furthermore, "evaluated" seems to be the wrong word in any case. For all but string, these attributes are required to be present if the office:value-type fits.
To say that an invalid attribute occurrence is simply not evaluated is misleading and not part of the definition of behavior for implementations, although that could certainly be implementation-dependent behavior, just as for any attribute that appears where the schema has no provision for it. Dennis pointed out correctly that on previous occurance was not covered. Added to the resolution:
8.1.3 Value Type Replace: "The table:value-type attribute specifies the type of value that can appear in a cell." with "The office:value-type attribute specifies the type of value that can appear in a cell." the other sections were changed accordingly to his suggestion. Errata 02 - ODF 1.2 Reconciliation. There are a few deviations in ODF 1.2 that apparently arose through the re-organization of the material. That is being handled by one or more tasks here, based on the attributes involved.
|
||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Applied
Major
ISO/IEC JTC 1/SC 34 N 1078 : DEFECT REPORT NUMBER JP2-14
