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: Re: [office] Excel 2007 != Ecma spec YEARFRAC. Not even slightly. What should we do?

On Thu, Apr 17, 2008 at 4:24 PM, Patrick Durusau <patrick@durusau.net> wrote:
>  Warren Turkal wrote:
> > By import filter, I meant the excel import filter for OO.o or other
> > import filters for other apps. Basis==0 should have a fixed
> > interpretation. It should depend on magic configuration or the like.
> > Another idea also just occured to me. Why don't we just use strings to
> > identify the bases. Then we could just reserve "msexcel_blah" for for
> > excel.
> >
> >
> >
>  Let me work that out to see if I understand (not necessarily the same as
> agreement):
>  So, ODF:
>  Would fix an interpretation of Basis==0 (some interpretation).

Sure. It would fix the interpretation of Basis==<whatever>, not just
Basis==0. The number of <whatever>s would be the number of different
algorithms that we support.

>  Define a mapping for the various Basis==0 interpretations used by others to
> some set of identifiers.

No. We'd simply identify other basis algorithms with other
identifiers. We could have an annotation doc that shows how
applications interested in importing from other formats can make use
of the bases. For example in that document, we may say says 6660 is
the reverse engineered MS Excel 2007 actual/actual algorithm and 6661
is the reverse engineered MS Excel 2003 30/360 algorithm and so on. It
would then be the job of the MS Excel import filter to properly change
the formula bases to the appropriate identifiers for compatibility's

>  Define a mechanism, possibly a string, that identifies the "Basis==0" used
> in the imported spreadsheet.

The suggestion of a string was meant to suggest using strings
_instead_ of the numeric identifiers. For example, we could use
ms_excel2007_actual_actual (or maybe even
com.microsoft/excel/actual_actual or
application/vnd.ms-excel/2007/actual_actual or something else) to
identify the reverse engineered MS Excel 2007 Actual/Actual algorithm
instead of an opaque number.

>  Require that the "Basis==0" "identification" be passed along with the
> spreadsheet when it is exported. (Note, this is our identification of the
> basis, not the original basis==0.)

No...the basis algorithms ids would be fixed in ODF. If you wanted to
export to another format, then, yeah, the representation of the basis
algorithm would have to change for the exported format. However,
that's totally outside of the realm of the ODF spec.

>  And do that for each basis. Yes?

Each basis would be identified by a unique string within ODF. We could
easily segregate the normal algorithms from the MS Excel compatibility
algorithms from the Lotus123 compatibility algorithms from the
SuperCalc4 algorithms. Heck, we could add as many algorihtms as would
be needed to achieve compatibility with as many different basis
algorithms as we could think of.

>  Question: I assume it is an error for a user to have a basis which we have
> not identified? I am assuming that would be an edge case but I suspect it is
> one that we need to provide for.

Sure. However, I think this would be application specific. Maybe some
apps assume a particular algorithm while others query the user about
which base to use. Some may actually understand basis algorithms that
aren't represented in the standard. I mean, what if we don't add
ClarisWorks spreadsheet compatibility algorithms in the spec. What
would all those folks with old CW docs do? :-P

>  I have little faith in the notion that we can arbitrarily define unique
> identifiers and expect others to use them. I realize that premise is the
> basis for some major initiatives on the web but history is littered with
> quests for universal identifiers, usually of the sort, "let's agree, we'll
> use my identifier." Not that it doesn't work, DNS being a good example. But
> that is also a case where the values have no semantic meaning to the average
> user. I suspect the greater the degree of semantic meaning to users the
> greater the resistance to a universal identifier. Hard to say but I have a
> bad feeling about any approach that over rides the semantics attached by
> users.

This idea is all about allowing ODF to represent other basis
algorithms for compatibility. If compatibility is the real goal, it
doesn't matter if the identifier changes once it is in an ODS versus
whatever it was before. It just matters that we are able to represent
what the identifier means. Then, the applications developers can make
sure that documents get converted to use the right bases.


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