[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?
Warren, 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). Define a mapping for the various Basis==0 interpretations used by others to some set of identifiers. Define a mechanism, possibly a string, that identifies the "Basis==0" used in the imported spreadsheet. 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.) And do that for each basis. Yes? 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. 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. Hope you are having a great day! Patrick > wt > > On Thu, Apr 17, 2008 at 3:21 PM, Patrick Durusau <patrick@durusau.net> wrote: > >> Warren, >> >> Warren Turkal wrote: >> <snip> >> >> >> >>>> It doesn't address the problem that different people may want >>>> basis==0 to mean different things. The only solution I see for that is >>>> >> to >> >>>> attach some parameter to the sheet (as I noted earlier), which can >>>> >> affect the >> >>>> mapping of the basis value to the algorithm used. >>>> >>>> >>>> >>> Yuck!....Why can't we just rely on the import filters in apps just map >>> to the correct bases on import. We certainly shouldn't standardize >>> magic variables that affect seemingly unrelated formula calculations. >>> As long as we document it clearly, there's no reason that app >>> developers cannot handle the conversion. >>> >>> >>> >>> >> I think David was referring to the problem of knowing what was meant by >> basis==0. Import filters won't help unless which import filter to apply is >> signaled in some fashion. In which case, why use an import filter at all? >> Simply apply the appropriate rule. Yes? >> >> >> Hope you are having a great day! >> >> Patrick >> >> -- >> Patrick Durusau >> patrick@durusau.net >> >> Chair, V1 - US TAG to JTC 1/SC 34 >> Convener, JTC 1/SC 34/WG 3 (Topic Maps) >> Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 >> Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) >> >> >> > > -- Patrick Durusau patrick@durusau.net Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]