RE: [office-formula] User-Defined Functions

[Eric Patterson <ericpa@exchange.microsoft.com>]

A few comments:

- While it would be nice to avoid name collisions, this is not a new problem.  Existing implementations (Excel) can have cases with name collisions.  In Excel, built-in functions always win in this case.

- We need to make sure that the syntax allows for specifying a workbook reference to the user-defined function given that ODF doesn't define an object model.  This would be equivalent to =book1.ods!User.Foo().

- If we specify the "user" prefix, we should be clear about what the expected behavior is when an implementation has a built-in function with the same name.

-----Original Message-----
From: robert_weir@us.ibm.com [mailto:robert_weir@us.ibm.com] 
Sent: Wednesday, June 16, 2010 8:38 AM
To: Eike Rathke
Cc: office-formula@lists.oasis-open.org
Subject: Re: [office-formula] User-Defined Functions

A specific example.  A company called Foo.com writes an extension library 
of functions for Excel.   One function is called Bar().   How should this 
functions be written out?

1) COM.MICROSOFT.Bar()?

2) COM.FOO.Bar()?

3) User.Bar()?

Approach #1 or #3 will lead to collisions.  Approach #2 is similar to how namespaces work with code libraries. It does not guarantee lack of collisions, but encourages providers of libraries to choose unique namespaces.

Also, consider that at some point we might have interoperable extension functions, meaning functions that are defined in terms of other standards, like XPath expressions, JavaScript or web services calls.  In that case, the extension function is not tied to any single implementation.  So it would not make sense to bind it to the editor's namespace, since the same extension function might be used in multiple editors.

So I wonder if we merely should describe a namespace mechanism and say that the default namespace is null and that the default namespace is reserved and no extension functions shall be in the default namespace. 
Whether extension functions use the namespace "User" or "COM.Foo" or "COM.Microsoft" is really none of our business.

A reasonable thing for an implementation to do would be:

1) When an end-user defines a new function, give it a namespace prefix,, either based on a GUID, the user's initials,time stamp or something else believed to be unique.  "User" would not be optimal since it would likely clash.

2) When writing a library of functions for re-use across spreadsheets, implementations might have to allow the user to assign a more meaningful prefix.

3) Where an implementation ships with its own built-in extensions, it should probably name them as COM.Microsoft.Excel or similar.

These are reasonable guidelines, but I don't think we need to specify these.  It would be enough to simply say that no extension functions shall use the default (null) namespace.


-Rob

Eike Rathke <erack@sun.com> wrote on 06/16/2010 10:06:36 AM:

> 
> Hi Robert,
> 
> On Thursday, 2010-06-03 11:42:12 -0400, Robert Weir wrote:
> 
> > > They have been briefly discussed. The outcome was that
implementations
> > > should write them prefixed with "USER.", this seems not to have 
> > > made
it
> > > into section 5.7
> > 
> > 
> > Should there any difference between an implementation-specific
extension 
> > function and a user-specific extension function?  I think there 
> > might
also 
> > be 3rd party libraries of extension functions.
> 
> Implementation-specific extension functions should start with domain 
> names as lined out in section 5.7, e.g. ORG.OPENOFFICE.* or
COM.MICROSOFT.*
> 
> I think the "USER." prefix should be applied to all extension 
> functions, user-defined or third party, that do not use the domain name approach.
> 
> > Main concern now is name collisions.  Simply saying
USER.CurrencyConvert() 
> > may prevent the name from colliding with future intrinsic functions 
> > in

> > OpenFormula that might use the name "CurrencyConvert", but it 
> > doesn't prevent collisions between two users with the same function name.
> 
> I don't see how we could prevent that. Introducing some sort of per 
> document prefix or UUID would still not help for or disable library 
> functions that have the same name on different systems / user 
> installations and are doing actually the same. We can only recommend 
> to library developers to use the domain name approach.
> 
>   Eike
> 
> --
> Automatic string conversions considered dangerous. They are the
GOTOstatements
> of spreadsheets.  --Robert Weir on the OpenDocument formula 
> subcommittee's list.
> [attachment "att5lxlz.dat" deleted by Robert Weir/Cambridge/IBM]

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php