David,
If I can jump in quickly on "named expression."
I note that in the formula spec you have defined a "PortableIdentifier"
that looks like an XML name to me. In other words, it would qualify as
an XML ID.
Is there some reason to not restrict the range of names for expressions?
Thinking that there should be a distinction between how I as a user
select the expression (its name), versus how the document actually
"identifies" the expression, which I would lobby to be an xml:id.
As written, it seems to me that you could very easily wind up with
conflicting names for the name expressions. (a bad thing)
The reason why this comes to mind now is that in reviewing all the
attributes it became evident that we haven't been consistent on the use
of xml:ids or names for identification. For what it is worth, I would
much rather make "names" (think displayed to users completely
unconstrained) and yet have guaranteed unique identifiers (xml:ids) for
expressions, elements, styleseheets, etc. That gives us a lot more
freedom with names and yet maintains a robust system of references.
As it is, we have names that are references, some with and some without
spaces, we have others that are simply display names, and we have yet
others that are subject to a number of restrictions in particular
contexts. Granted all that is doable but it seems untidy and error prone.
I realize this will require extended discussion by the TC but I wanted
to get some discussion started on the issue of using names for references.
Hope you are having a great day!
Patrick
David A. Wheeler wrote:
> 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
>
>
--
Patrick Durusau
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)
