[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Updated: (OFFICE-3042) Planning for futurefunctions / User-defined functions
[ http://tools.oasis-open.org/issues/browse/OFFICE-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Eric Patterson updated OFFICE-3042:
-----------------------------------
Proposal:
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 original function name itself.
was:
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, evaluators may omit a prefix. Evaluators 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 original function name itself.
Updated to reflect Andreas' comment
> Planning for future functions / User-defined functions
> ------------------------------------------------------
>
> Key: OFFICE-3042
> URL: http://tools.oasis-open.org/issues/browse/OFFICE-3042
> Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
> Issue Type: Bug
> Components: OpenFormula
> Affects Versions: ODF 1.2 CD 05
> Reporter: Eric Patterson
> Assignee: Eric Patterson
> Fix For: ODF 1.2 CD 06
>
>
> CD05 indicates that functions that are not part of the spec should be written out using a prefix (com.microsoft...). This causes problems with user-defined functions as well as future functions to be defined later. There has been discussion about adding the "User." prefix to user-defined functions, but how do future functions fit in?
> Assuming that a new function is added in ODF-Next, implementers of ODF 1.2 may read a future file and encounter one of these future functions. It will be unclear how to treat the future function without some designation. We want to avoid future functions being tagged with "User."
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]