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


Thanks for the clarification.

Though, a small nitpick if I am allowed:

Cell references are marked/surrounded by: [...]

I wonder IF a proper tag wouldn't be more future oriented.
Something like:
<ref>....</ref>
and
<name>...</name>
(or something similar)

Of course, implementations will vary in how they display it on screen, 
but ODF should remove any ambiguity and remain open for any future changes.

My 2nd complain is about the default handling of names/ranges:
 - IF a named range/expression is defined, then
   the user most likely wants to use this named range/expression
 - not the reference the string 'points' to

Therefore, I would prefer that whenever there is an ambiguity between a 
named range and an actual cell/range, the named range/expression be 
used. The user wouldn't have named it like that, IF he needs to point to 
that particular column.

Sincerely,

Leonard


David A. Wheeler wrote:
> Leonard Mada:
>   
>> a recent bug-report [1] on the OOo-site points to a more fundamental problem
>> of ODF, especially of column naming vs named expressions/ranges.
>> [1] http://www.openoffice.org/issues/show_bug.cgi?id=90230
>>
>> The problem is not bound to the OpenOffice implementation,
>> though I will describe it based on OOo:
>>
>> OOo 2.4 currently supports 65535 columns, therefore:
>> 'ST1' is a valid name (expression, range, ...).
>>
>> However, with OOo 3.0, this limit will be moved upward,
>> so that 'ST1' will be now a valid column [cell].
>>
>> Ad extremum, IF we consider a very distant future (why not in 10,000 years ;-) ),
>> then any string used currently as name will probably point to a valid column.
>> [IF only string, then the whole column, IF string_number_ then a cell]
>>
>> It is unsafe to assume that the current column limit will be held
>> [or any other column limit], and changing this limit in the future
>> will jeopardise existing names.
>>
>> I propose to enhance the ODF as follows:
>>  - names should be marked explicitly as such within formulas
>>  - this will allow to unambiguosly identify a name as such in the future
>>  - this will be especially improtant, IF the spreadsheet evolves
>>    to something basically limtless, when every name will point to
>>    a cell/column
>>     
>
> Hi - we knew about this potential problem at the beginning of the
> definition of OpenFormula, and have already addressed it.
>
> In the exchange format, _ALL_ cell references are surrounded by [...],
> while named expressions (variables) are not.  In addition,
> to enable handling really odd expression names, you can prefix a named
> expression with $$,  Thus, ST1 is a variable, as is $$ST1, while [.ST1]
> is a cell reference.  See section 5.8 for cell references, and 5.11
> for named references.
>
> OpenFormula doesn't mandate any particular user interface, but
> the likely implementation would be that "text that looks like a cell
> reference" would be turned into a cell reference, and some indicator
> (like $$) would disable that.  The key is that the _exchange_ format
> is unambiguous, and works no matter how many rows/columns are allowed.
>
> --- David A. Wheeler
>
>   



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