[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Proposal: Identifying nonstandard functions
There have been several comments on identifying nonstandard functions that I think move in similar directions, and that's a good sign. First, a summary: Robert Weir: > That doesn't seem significantly different from us acting > as a registrar... In practice, other namespaced languages with far > more producers than ODF, things like Java or C++, have > managed to avoid namespace collisions.. Nathaniel S Borenstein noted: > If we go for something less structured like dot-separated > namespace, we should also specify a convention for namespaces, > probably linked to domain names like Java objects and such... Michael Brauer: > 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. The references to Java and "including their organization" all suggest that many people would be more comfortable with Java-like prefixes, e.g., reversed DNS names as the prefix. I think this is probably the best way forward; it eliminates the need for a new registar (DNS acts as our registrar) AND it eliminates the need for namespace information while processing formulas. If we recommended using only enough of a reversed DNS name to ensure that the organization owns the namespace, the resulting names are actually not that long (surprisingly). E.G.: COM.MICROSOFT.FOO(5;1) ORG.OPENOFFICE.BAR(7) COM.IBM.CAMELOT(8) ORG.GNUMERIC.XOR(1;1) # Gnumeric really does own gnumeric.org. Since the prefix is a fixed string, it should compress well. One in the namespace, organizations can subdivide the namespace further (e.g., to differentiate between the 2003 and 1998 version of FOO if they had different semantics). I expect a vast majority of functions to be simple, standard ones like SUM and MAX, so I believe having longer names in these special cases is not a problem. We should also define the "implied prefix" of standard functions, e.g., "ORG.OASIS" or "OPENFORMULA". If we did the former, that just means that "SUM" is really "ORG.OASIS.SUM". Then in the future we could still have COM, NET, NAME, etc. packages; we'd just have to explicitly write the prefix. We could claim that "ERROR" and "SQL" will never be top level domains, if we wanted to avoid prefixing them. Are we converging? --- David A. Wheeler
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]