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

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-formula message

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


Subject: Re: [office-formula] Proposal: Identifying nonstandard functions


> I don't think we want to get into the registrar business.  A vendor can 
> figure out how to create a unique function name if they want to create 
> such an extension, whether 123.DAYS, or 123_DAYS, or whatever.  If we want 
> to recommend a mechanism, then that's fine.  But creating a registry is 
> overkill.  As you said, the number of applications is relatively small.
> I look to XPath as a good implementation example here.  They allow custom 
> functions, and allow them to be namespaced.  But over the years I have not 
> heard of problems caused by vendors colliding in names.

I'm amenable to that, though we may get pushback.
But we need to specify the specific syntax for identifying
application/library-specific functions.  Actually, I think we're
automatically moving in the same direction, some sort of
prefix needs to be used to identify "this is an extension, and whose".

We can't use the traditional namespace reference syntax using a ":",
e.g., EXCEL:FUNKFUNC(...),
because that looks identical to "call named expression Excel, call
standard function FUNKFUNC(), and then determine the range
between them".

It's tempting to use namespaces, and have the syntax be
PREFIX.NAME, as I had proposed earlier.  The only change there
is that EXCEL.FUNKFUNC implies that there is a namespace EXCEL
defined in scope.  We should still include "recommended" prefixes,
for readability.  That keeps us from being the registrar.
We will probably get a little pushback on that.

We could use a distinguished syntax; suggestions?

Also: You can't say "123.FUNC", because that looks like a number
followed illegally by a function name.  Which is why I used LOTUS there.
I don't think think we want to munge the syntax to permit that.

--- David A. Wheeler


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