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] Re: [office-formula] Proposal: Identifying nonstandardfunctions

"David A. Wheeler" <dwheeler@dwheeler.com> wrote on 07/26/2006 12:42:26 AM:

> 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 doesn't seem significantly different from us acting as a registrar.  We're still selecting vendors and assigning identifiers.  In practice, other namespaced languages with far more producers than ODF, things like Java or C++, have managed to avoid namespace collisions without calling out any specific namespaces in their specifications other than the reserved namespaces for the standard itself.  So I think we'll be safe here even if we don't call out namespaces for a handful of specific vendors.

> 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 think it would work even without connecting to a declared XML namespace.  The grammar already allows a period character to be part of function names.  So we could just add a comment that this can be used to disambiguate custom or vendor-specific function names.

Another simplification would be to drop the "of:" prefix and say that formulas by default are formulas according to this specification, and that only alternative formula languages are required to be namespaced.  That's gets rid of the attribute namesapces altogether in the most usual case.  Of course, all vendors are using the default namespace in ODF 1.0 and ODF 1.1, but this will be unambiguous, since ODF 1.2 documents will have a 1.2 version tag, and we can distinguish implementation-defined formulas in ODF 1.0, from default OpenFormula formulas in ODF 1.2.

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