OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] Issue Comment Edited: (OFFICE-2332) LogicalNumber material appears under Logical Boolean



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

Dennis Hamilton edited comment on OFFICE-2332 at 1/27/10 1:11 PM:
------------------------------------------------------------------

Andreas,

When existing implementations are strongly incompatible (in that interoperable behavior is not achievable), how does one specify a standard for that?

If the difference could be isolated to choics made by the OpenFormula-hosting specification, that would be great.  That specification might still punt to implementations for it, and that's probably fine too.

But for OpenFormula, what would work as a neutral specifcation?

One way, off the top of my head, would be to not recognize a Logical type at all.  Document formats that have logical types in cells could clearly do the casting via x<>0 and could do the conversion for references that access values of their logical type in delivering cell values for the evaluator.

This does leave ISNUMBER and ISLOGICAL to deal with.  One could require that they only accept references as parameters and leave it up to the hosting to prescribe how these are answered (punted to implementations as appropriate) in a way that matters with regard to he semantics of counting, making Number sequences, and so on.

This would provide a basis for OpenFormula-hosting specifications and their implementations digging their way out of the inconsistencies over time, while providing a coherent OpenFormula specification.  (I could see implementations adjusting for when OpenFormula formulas are used versus some legacy formula syntax and semantics, if necessary.)

I am not wedded to the above, but you can see how much simpler and consistent this makes the OpenFormula role.  

Maybe we just need to think out of the box on how OpenFormula becomes a force for interoperability rather than legitimize incoherence.  It will be much harder to fix later once incoherence is made conformant and wired into OpenFormula itself. 



      was (Author: orcmid):
    Andreas,

When what existing implementations are strongly incompatible (in that interoperable behavior is not achievable), how does one specify a standard for that?

If the difference could be isolated to choics made by the OpenFormula-hosting specification, that would be great.  That specification might still punt to implementations for it, and that's probably fine too.

But for OpenFormula, what would work as a neutral specifcation?

One way, off the top of my head, would be to not recognize a Logical type at all.  Document formats that have logical types in cells could clearly do the casting via x<>0 and could do the conversion for references that access values of their logical type in delivering cell values for the evaluator.

This does leave ISNUMBER and ISLOGICAL to deal with.  One could require that they only accept references as parameters and leave it up to the hosting to prescribe how these are answered (punted to implementations as appropriate) in a way that matters with regard to he semantics of counting, making Number sequences, and so on.

This would provide a basis for OpenFormula-hosting specifications and their implementations digging their way out of the inconsistencies over time, while providing a coherent OpenFormula specification.  (I could see implementations adjusting for when OpenFormula formulas are used versus some legacy formula syntax and semantics, if necessary.)

I am not wedded to the above, but you can see how much simpler and consistent this makes the OpenFormula role.  

Maybe we just need to think out of the box on how OpenFormula becomes a force for interoperability rather than legitimize incoherence.  It will be much harder to fix later once incoherence is made conformant and wired into OpenFormula itself. 


  
> Logical Number material appears under Logical Boolean
> -----------------------------------------------------
>
>                 Key: OFFICE-2332
>                 URL: http://tools.oasis-open.org/issues/browse/OFFICE-2332
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Bug
>          Components: OpenFormula
>    Affects Versions: ODF 1.2 Part 2 CD 1
>            Reporter: Patrick Durusau
>            Assignee: Patrick Durusau
>
> Logical Boolean now includes:
> ***
> Logical values may be implemented as a distinct, distinguishable type from numbers, so that ISNUMBER(TRUE()) and ISLOGICAL(1) evaluates to FALSE(). However, logical values may also be implemented as a subtype of Number, where TRUE() simply returns 1 and FALSE() simply returns 0. Note that due to the implicit conversion operator "Number to Logical" (discussed below), when a number is passed as a condition, 0 is considered False and all other numeric values are considered True.
> ***
> Should appear as subtype of number.

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