Having a registration service is a pain,
but sometimes it is by far the best alternative. The IETF has a registration
service that works pretty well for stuff like port numbers and MIME types.
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. But we
should do something in advance to really discourage namespace collisions.
-- Nathaniel
"David A. Wheeler"
<>
07/26/2006 12:42 AM
Please respond to
To
,
cc
Subject
[office] 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
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs
in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
