Re: [office] Re: [office-formula] Proposal: Identifying nonstandardfunctions

[Michael Brauer - Sun Germany - ham02 - Hamburg <Michael.Brauer@Sun.COM>]

Rob,

robert_weir@us.ibm.com wrote:
> 
> 
> "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.

I agree.
> 
>  > 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.

I'm not sure about this. I think namespaces currently don't collide because 
most implementors choose hierarchical names that include their organization. 
If we specify that custom function names have to be hierarchical, then this 
will work but will also lead to very long function names. If we use only 
prefixes or non-hierarchical names, then I think we will get collisions. So, 
I don't know whether it is better to use hierarchical function names or to 
use XML namespace (the formula SC will know that better than me), but I think 
the names we use to identify custom functions have to be somehow hierarchical.

> 
> 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.

This sounds like a good idea.

Michael