On Tue, Oct 18, 2005 at 02:39:36PM -0400, David A. Wheeler wrote: > > * Agree on specification license & eventual standardization process. - Rather than re-inventing this wheel do we want to just adopt the process from one of the ISO/JTC/WG groups or possibly as a subset to OASIS ?
- We will likely need different licenses for the spec and for the validation suite. > But the real measure in my mind is: > can users can easily exchange data with formulas between > many different implementations? For marketing purposes we should probably make it clear that 'implementation' includes different versions of the same application. > * Scope & Basic principles. We're doing that now; I expect those > to end up in chapter 1-2. One key issue: What's our starting point? > Currently, for syntax I plan to use OOo unless strongly contraindicated. Current OOo syntax has a few limitations we may want to address. - It does not support full col/row references eg A:B seems more portable between versions than A1:B65535 (in the context of max size changes) - A1 notation is reasonable, but R1C1 would be more amenable to sharing and compression. > (Excel, OOo, KOffice, Gnumeric, etc.), making sure that we do NOT > specify anything that contradicts the widely-used Excel. amen. > Over time we can then work to constrain things further. > In the end, I think the _semantics_ should be > "as close as possible to Excel" The Gnumeric development motto is 'As close to Excel as necessary but no closer' > But some spreadsheet implementations have variances, and if > they're unwilling to change, perhaps we should define "levels" > so that users will know what they can depend on... and what they > can't. If we agree that a validation suite of test workbooks is required we could use the scores from those (foo conforms 93%) > * Types (Current chapter 4). What are they? How much should > we say about subtypes (e.g., date)? At minimum we should agree on a standard set of errors. Err.511 vs #NA types of thing. More expansively we'll need to at least discuss bounds and types. eg MS Excel's RK structure provides a window into some of the issues. Standardizing the bound does not seem useful, but providing guaranteed minimums would be useful > * Semantics of built-in operators (+ - * / etc.), logical operators. http://www.gnome.org/projects/gnumeric/func-tests/operator.xls > * Function definitions. We need to define a template, and then > fill them in. It's been proposed to start with date/time (sounds fine!), > but we should also work to define a few of the most common ones > like SUM and COUNT. Rather than doing a full set of similar functions I would rather start by doing the 10 most common functions to get a feeling for the the diversity we'll need in the spec. At the same time I'd like to see a spec for how an application should construct/name non-conforming functions and a discussion of best practices for handling functions that are known to differ between implementations. eg LOG vs LOG10 > * Other. I think we should note recalculation order as a topic for > a later edition, but not START there. Additional material would include - iterative expressions - array expressions - implicit type conversions - ?? natural language refs ?? ... _______________________________________________ gnumeric-list mailing list gnumeric-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnumeric-list