[OASIS Issue Tracker] Commented: (OFFICE-3427) 8.3 Auto Text toNumber

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

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

Patrick Durusau commented on OFFICE-3427:
-----------------------------------------

Do we really need this language? We define conversion from number to text (as being implementation defined). 

Suggest we point out 6.3.5 Conversion to Number and 6.3.14 Conversion to Text and thank them for their contribution. 

Plus delete 8.3 as unnecessary. 

> 8.3 Auto Text to Number
> -----------------------
>
>                 Key: OFFICE-3427
>                 URL: http://tools.oasis-open.org/issues/browse/OFFICE-3427
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Sub-task
>          Components: OpenFormula
>    Affects Versions: ODF 1.2 CD 05
>            Reporter: Robert Weir 
>
> 8.3Auto Text to Number
> An evaluator may have the “Auto Text to Number” feature, which means
> that the “Convert to Number” function, when receiving a Text value or
> a Reference to a Text value, converts the Text into a Number,
> typically through calling the VALUE() function. This feature can be
> convenient if files never change locale, but in today's international
> environment, this feature can easily lead to data files that look
> correct but give subtly wrong answers, especially when shared with
> users who use a different locale. This can be a problem even when the
> documents never leave a small geographical area, since users may
> choose a locale they are familiar with that is different that the one
> expected by the document sender.
> This is perfectly solvable.
> Let me explain.
> The environment needs to be split in two. One internal representation
> and one UserInterface representation.
> The internal representation holds a standardized locale. And the
> UserInterface has also a local.
> The programs can compare the two and calculate forth and back between
> those, while the internal representation remains stable.
> Means documents that can be read with any local because it's not
> dependent upon the UI localization.
> User can input things that get (in a stable way) converted to the
> internal representation and forth to display everything.
> Allows for doing a Auto Text to Number.
> Works as following:
> A preparing function takes the text and converts it to the internal
> representation locale according to localization transformation rules.
> Now our Function can take that, which is the same everywhere, and
> converts it according to the internal representation local.
> The program then, for showing, does the regular transformation between
> internal representation locale and user interface locale.
> There are of course strange edge cases that will always be very
> difficult to solve.
> But having a simple way to do simple things looks very good possible
> in a standards-compliant locale-independent way.
> This also allows collaboration wit people from different locale on the
> same document.

-- 
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