[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=21198#action_21198 ] 

Andreas Guelzow  commented on OFFICE-3427:
------------------------------------------

OPENFORMULA is not concerned about the user interface.

Of course is a user types the string "123,123" there is no way for the program to know whether this is an ordered pair of two numbers just above 100 or a single number. In fact users may want to use the same string in both senses, so the implementation cannot store it "appropriately". 

> 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