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


Help: OASIS Mailing Lists Help | MarkMail Help

office message

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

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

Recap: Different spreadsheet applications can have different formula functions,
and we want applications to be free to create new functions without
interfering with other applications.  This is one of the
requirements in the formula subcommittee charter.

I posted a proposal and asked for comments.  In it, I said:
"I don't think we need to use XML namespaces for this...
and we could probably have OASIS act as the registrar for names."

Robert Weir disagreed, and said:
> > I don't think we want to get into the registrar business.

Michael Brauer also stated:
> I agree to Rob. I think a registration business is outside the scope of the 
> OpenDocument TC, and I believe also outside the scope of OASIS.
> I further think we have to differ between using XML namespaces for the 
> identification of extensions/implementations, and the use of 
> [prefix]:[local-name] syntax of XML namespaces. If it is not possible or 
> reasonable to use a colon within formulas (and I have no doubts that this is 
> the case), then I think it is better to use a dot instead and to keep the 
> other semantics of XML namespaces, then it would be to define a new 
> extension/identification method.

Thanks for the feedback, very helpful indeed.

Okay, here's a new proposal: function names can have "."
in them; if they do, AND the leftmost portion matches an
active namespace (there), then that namespace is used to identify
WHICH function that is.  The syntax is different than traditional XML
namespace notation, because ":" does indeed mean something
VERY different in formulas!   This gets us out of the registry
business.  This means that function-processing applications
will need to get not just the attribute value but also the
set of namespaces, but there are tools that do that.
Yes, I know some people are uncomfortable with this approach.

I think we should spec a predefined set of standard
prefixes, to aid readability, and we should identify
namespaces for common current spreadsheets.  Those pieces
of information should so help bootstrap the process.

That means you could define "OOO" as a namespace
(pointing to, say, "http://openoffice.org/";), and a function could
look like this:
 <table:cell table:formula="of:5+OOO.ROUNDDOWN([.A1];1)">...
Applications are perfectly free to implement the functions
originally developed elsewhere; indeed, that creates a very
nice system for applications to create new functions, and the ones
that "catch on" can port and eventually move into the standard.

Comments? Horrors?  I know some people don't like
namespace id's in attribute values, but it DOES solve a problem
(not needing a central registrar).

I'm posting this to both the "office-formula" and "office" mailng lists:
* "office-formula", since this affects recalculated formulas directly.
* "office", since some may object (and I want to know if that's
    a problem NOW)... and also because it affects the containing
    document (now you need to put in the namespaces).

Thanks for your comments!!

--- David A. Wheeler

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