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

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-comment message

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


Subject: Re: [office-comment] Conceptual Problem: Ambiguity for Names usedin Formulas


> Well, references are currently saved as '[...]', but I would like to see 
> more vector-capabilities in spreadsheets.

We already represent arrays using {...}. Vector/Matrix slices
could be represented using function notation (for example),
so using [...] does not impede future capabilities.
At this point, I think it's highly unlikely that this syntax will change;
we've had the spec up for years, and implementors have already
been implementing it.

> I would strongly oppose adding a new identifier (like '[', '{', what 
> else? ) for every new type of object.

But to many people, speed of loading or simplicity of
implementation is very important.
Using the first character to disambiguate is an easy way to
aid both, so where we can do that for common cases, it's
worth doing.

> Syntax: PERCENTILE( NumberSequence Data ; Number x )
> Syntax: PERCENTILE( NumberSequence Data ; NumberSequence x )

An interesting idea.

However, we're trying to fix any last errors and get
THIS version out-the-door as a Committee draft standard.
I'd like to release a Committee draft this month.
I suggest waiting to propose anything that is NOT already implemented
in an existing spreadsheet application.  Instead,  I suggest focusing
on errors in the existing spec.

One main point of this specification is that any implementor
can create a function using a namespaced-like function name
(e.g., ORG.OPENOFFICE.PERCENTILE).  Once they do so,
others can immediately start implementing it too.  Later on, the
specification developers can create a function with that
semantic - or a different one, based on lessons learned.
Thus, we do not have to define all possible useful functions
in this version of the spec.  Instead, we need to get a spec out
there that lets each implementor create their own additional
functions - and lets others implement them - and then it can
be standardized based on lessons learned.

--- David A. Wheeler


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