[OASIS Issue Tracker] Commented: (OFFICE-1898) CHAR and CODE areinconsistent

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/OFFICE-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12140#action_12140 ] 

Dennis Hamilton commented on OFFICE-1898:
-----------------------------------------

I went mining in IS 29500-1:2008 to see if there was any help in the OOXML counterparts of these spreadsheet functions.  I was disappointed by the lack of reconciliation among these functions there.  I would stick with the recommendation here, although I think there is more that needs to be done with regard to "the implementation's character-set representation for text."

> 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
>            Priority: Blocker
>
> 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