Planning for future functions / User-defined functions

5.7 Nonstandard Function Names When writing a document using function(s) not defined in this specification, an evaluator shall include a prefix in such function names to identify the original definer of the function's semantics. When the origin of a function cannot be determined, producers may omit a prefix. Producers may use the prefix to differentiate between different definition types. Evaluators that do not support a function should compute its result as some Error value other than NA(). 5.7.1 Implementation Defined Functions Implementation Defined Functions should include a prefix beginning with a domain name owned by the definer, in reverse order, and should be in uppercase letters (where lower/uppercase letters apply). This prefix should be the shortest prefix sufficient to identify the application company/project, followed by a period, optionally followed by version information or more specific product identification and a period, followed by the original function name itself. The version information should be included if an application substantially changes the semantics of a function (as viewed by users of that function) and one of those later versions of the function is intended. Evaluators may implement functions originally defined by another evaluator, and thus may read and/or write function names that use another evaluator's prefix. Note: Examples of such names include COM.MICROSOFT.CUBEMEMBER, ORG.OPENOFFICE.STYLE, ORG.GNUMERIC.RANDRAYLEIGH, and COM.LOTUS.V98.FOO. Evaluators should avoid defining evaluator-unique functions beginning with a top-level domain name followed by a period. Evaluators should avoid defining application functions beginning with "NET.", "COM.", "ORG.", or a country code followed by a period. 5.7.2 User-Defined Functions Functions defined by users should include a "USER" prefix, followed by a period and the function name. (modified by pld, 26Oct2010)