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

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-formula message

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


Subject: Re: [office-formula] Key Issues


Hi Daniel,

On Sat, Feb 25, 2006 at 22:41:28 +0000, Daniel Carrera wrote:

> The only drawback of levels is that we might see spreadsheets complying 
> to level 1 only and then saying to their customers "we're compliant". 
> For this reason, I'd like level 1 to be good and meaningful for the 
> average user.

How do we identify the average user? The average bank clerk has other
needs than the average home user than the average engineer.


> I don't know about levels >1 but I think that it's important that level 
> 1 be complete enough to guarantee interoperability for most users. I 
> wonder, is this goal compatible with the goal of making level 1 suitable 
> for tiny PDAs?

I'm not familiar with tiny PDAs, what function set do they support?


> * As a developer, I don't want the spec telling me how to do UI. That is 
> none of the spec's business.
> * UI considerations may be incompatible with interoperability goals.
> * Adding UI requirements will only create a gratuitious barrier. No one 
> will change their UI just to comply with OpenDocument. Even I might not.
> * UI considerations would make the spec much larger for no benefit that 
> I can see.
> * OpenDocument doesn't include UI.

5 very valid points. Thanks.


> test cases == lower barriers to adoption
> 
> Isn't this one of the reasons why OpenDocument uses RelaxNG instead of 
> DTD? Because RelaxNG allows you to make a more precise automated test?

Isn't that more because OASIS endorses RelaxNG and RelaxNG is going ISO?
Honestly, I've no idea.


> >Wheeler  believes it is VERY difficult to write unambiguous text,
> 
> Mathematical information is easier to convey in mathematical language.
> 
> Formula spec == mathematical information.
> Test cases == mathematical language.
> 
> >* Discuss use of Wiki.  Do we want to try to put stuff in a Wiki
> >and LATER transition text to ODF? Transition to an ODF document NOW?  
> 
> We have to use the OASIS wiki, right? Can non-OASIS people use the OASIS 
> wiki?

What I have understood, OASIS resources can only be used by OASIS
members, which is good in terms of copyright because a member declares
to only contribute work he owns the copyright for, and every committee
work has to be done using OASIS resources for transparency.


> >One issue: The Wiki must be MoinMoin, and it's unclear if OASIS will
> >install the MoinMoin math formula support.  Without formula support,
> >formulas may be harder to create.
> 
> Formulas are hard to create with OpenDocument tools also. And I don't 
> fancy using LaTeX for the spec.

What about OOoMath?


> I don't like the "strict" vs "loose" idea. I'm ok with the levels idea, 
> but in general I'd prefer to define scemantics strictly.

The problem with defining semantics strict at the moment is that there
are several semantics and only a few applications do it identical, if at
all.

> poor scemantics == poor interoperability

Strict defined semantics == at most 2 applications supporting it.


> I don't think that strict scemantics have to be a problem as long as the 
> formula spec also provides explicit type conversion functions. Consider 
> this example:
> 
> * In BobOffice "3"+3 is 6.
> * In AlliceOffice "3"+3 is an error.
> * Take this spreadsheet in BobOffice
> 
>      A
> 1  "3"
> 2   3
> 3  =A1+A2
> 
> When I *save* this spreadsheet in BobOffice, the cell A3 could be saved as:
> 
> =StringToNum([.A1])+A2
> 
> 
> Now, when I open the file in AliceOffice, AlliceOffice sees the explicit 
> conversion and gives me the appropriate result.

Except if A1 contained "3,1" or "12.345,67" or "1/2/3" (intended as
date). And what is "12'234.56"?

> CONSEQUENCES:
> 
> * Now we have interoperability.
> * BobOffice doesn't have to change the UI.
> * But BobOffice and AliceOffice must implement a StringToNum() function.

Which wouldn't help without information about which input locale the
string originated from.


  Eike


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