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

Leonard Mada:
> 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)

We don't want to do that SPECIFIC thing.  These are contained as
attributes inside an XML file, so using XML markings would probably
be confusing.  In any case, it's not needed.

> 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.

There's NEVER any ambiguity in the exchange format:
* If it's a cell reference, it is ALWAYS surrounded by [...].
* If it's a named expression, it is NEVER surrounded by [..].
Most named expressions are simply referred to by name,
but if you want to begin the name itself with
'[' or include other "odd" characters, you have to start the name
with the special escape format "$$" that ALWAYS introduced
the name of a named expression.

So you just need to look at the first character, and that determines
whether it is a cell reference or name of a named expression.
There's no need for special disambiguation rules.

Here's an example, perhaps that will make it clear:
 A1 is a named expression, whose name is A1
 [.A1] is a reference to the cell A1

> 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.

Again, there's no ambiguity in the exchange format, so there's
no need for a rule to disambiguate it.  So if you want to create
a named expression named "A1", you can exchange it.
(It's not a good idea, because it could confuse people, but you CAN express it.)

Now for the user interface, the rule you give is
usually a good idea, and I believe it's what most apps do already.
But the user interface is out-of-scope for the
formula spec.  People can (and do) change the user interface.
In fact, in at least one spreadsheet application
(Word Perfect's Quattro Pro), the user interface
is a run-time setting you can change while running the app.
Function names tend to change based on the locale, too.
Which is why we've concentrated on the _exchange_ format, and
not the user interface - there's lots of variance in the user interface.

--- David A. Wheeler

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