MHonArc v2.5.0b2 -->
office message
[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]