[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Updated: (OFFICE-1898) CHAR and CODE areinconsistent
[ http://tools.oasis-open.org/issues/browse/OFFICE-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Eike Rathke updated OFFICE-1898:
--------------------------------
Proposal:
Mark CODE and CHAR functions as deprecated and non-portable.
Add recommendation to use UNICODE and UNICHAR functions instead.
CODE(CHAR(N)) for 1<=N<=255 only.
was:
1. In 6.19.2 CHAR,
1.0 Change the Syntax to use "Number n" rather than "Number N".
1.1 Change the Returns to "Text of length 1"
1.2 Change the Constraints to simply "n >=0" (should really use the correct glyphs for >= and <=, rather than programming/OpenFormula notation?)
1.3 Add constraint "n <= implementation-defined-limit" if language about such a thing is introduced into OpenFormula. But this can be handled more-specifically in the text.
1.4 Portable Constraints are, I think, that the implementation support an internal character-set encoding in which code points 0 to 127 are those of the ASCII character set, corresponding to the Unicode code points for C0 Controls and Basic Latin, U+0000 through U+007F. [Note that these are not good portable constraints for text characters, but they are good for being able to count on having those codes available as unsigned values in bytes.]
1.5 Semantics. "Returns the text string consisting of the single character that corresponds to code-point value INT(n). If INT(n) is not the value of a permissible code point in the implementation's character-set representation for text, the result is implementation-defined. The result is implementation-defined if n is not an exact integer or its value exceeds the implementation-defined maximum for code-point values. INT(n) = CODE(CHAR(n)) shall apply whenever INT(n) is accepted as the unique code point of a text character by the implementation."
1.6 Change "Test Cases" to "Examples"
1.7 In the first example, change the description to "Assuming ASCII or Unicode text-string representation"
1.8 in the second example, change the description to "assuming 10 is an acceptable character-set code point, e.g., U+000A for the Unicode LINE FEED character"
Changed the proposal to "mark as deprecated".
For the records, the Proposal field previously was filled by Dennis with the following text:
1. In 6.19.2 CHAR,
1.0 Change the Syntax to use "Number n" rather than "Number N".
1.1 Change the Returns to "Text of length 1"
1.2 Change the Constraints to simply "n >=0" (should really use the correct glyphs for >= and <=, rather than programming/OpenFormula notation?)
1.3 Add constraint "n <= implementation-defined-limit" if language about such a thing is introduced into OpenFormula. But this can be handled more-specifically in the text.
1.4 Portable Constraints are, I think, that the implementation support an internal character-set encoding in which code points 0 to 127 are those of the ASCII character set, corresponding to the Unicode code points for C0 Controls and Basic Latin, U+0000 through U+007F. [Note that these are not good portable constraints for text characters, but they are good for being able to count on having those codes available as unsigned values in bytes.]
1.5 Semantics. "Returns the text string consisting of the single character that corresponds to code-point value INT(n). If INT(n) is not the value of a permissible code point in the implementation's character-set representation for text, the result is implementation-defined. The result is implementation-defined if n is not an exact integer or its value exceeds the implementation-defined maximum for code-point values. INT(n) = CODE(CHAR(n)) shall apply whenever INT(n) is accepted as the unique code point of a text character by the implementation."
1.6 Change "Test Cases" to "Examples"
1.7 In the first example, change the description to "Assuming ASCII or Unicode text-string representation"
1.8 in the second example, change the description to "assuming 10 is an acceptable character-set code point, e.g., U+000A for the Unicode LINE FEED character"
> CHAR and CODE are inconsistent
> ------------------------------
>
> Key: OFFICE-1898
> URL: http://tools.oasis-open.org/issues/browse/OFFICE-1898
> Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
> Issue Type: Bug
> Components: OpenFormula
> Affects Versions: ODF 1.2
> Reporter: Dennis Hamilton
> Assignee: Eike Rathke
> Priority: Blocker
> Fix For: ODF 1.2
>
>
> In 6.19.2 CHAR in OpenFormula working-draft OpenDocument-formula-20090508.odt, it is recommended that CHAR(n) for n > 255 have an error-return result, while also recommending that the identity transformation n = CODE(CHAR(n)) be preserved.
> 6.19.4 CODE has an implicit requirement that c = CHAR(CODE(c)) be preserved for c a single-character string although CODE behavior is implementation-defined when c has a code-point greater than 127 in the internal representation of strings (which section 4.1 is not exactly definitive about).
> There seems to be quiet neglect for the possibility of "code pages" where the code points from 0 to 127 are not those of the ASCII code. There are other difficulties around strings being used to carry arrays of bytes that are not safe as strings in the implicit character-set encoding.
> I think there needs to be work on clear-cut abstractions for distinguishing internal representations, disguise of a different representation in the stored form of the internal representation, and in the interpretation of string constants and string values as text.
> These proposals are intended to help in movement in that direction.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]