W3C home > Mailing lists > Public > www-forms-editor@w3.org > November 2002

RE: [www-forms-editor] <none>

From: Mark Birbeck <Mark.Birbeck@x-port.net>
Date: Tue, 26 Nov 2002 15:00:07 -0000
Message-ID: <E3ED00A7C285EE408679DE2A26D1C7818FFCAE@S007.x-port.net>
To: "'Mark Seaborne'" <MSeaborne@origoservices.com>, www-forms-editor@w3.org


Mark Seaborne wrote:
> [On namespace prefixes for functions] Being a user, rather than an
> implementor I feel I should resist looking at the CR to see if that
> gives any clues ....

Quite right ... wouldn't want you peeping behind the curtains! You never
know what you might find ;-)

As it happens, the spec doesn't have namespace prefixes. I've been meaning
to write something on this, so I'm glad you asked.

> The first question arising is, should browsers require XForms functions to
> in the XForms namespace? FormsPlayer does, the Novell browser does not,
X-Smiles does.

There's two approaches to this. The first is to say that the XForms spec can
do what it wants. If it wants to have its functions in 'no namespace' then
it can. It would after all be following the precedent of XSLT 1.0, for
example, in adding functions to XPath.

However, we took a different approach for a couple of reasons:

* modular and reusable code
* XPath 2.0

One part of the architecture of FormsPlayer is a DLL called DOM3XPath. This
module near enough implements the DOM Level 3 XPath working draft. Of course
this is still only a WD, but we always take the approach of 'start as you
mean to go on', and have found it extremely useful as a way of centralising
all of our XPath functionality into one place. One of the features that we
have in this module is the ability to attach an external library of
functions, using a namespace prefix to reference the functions. This means
that from an implementation point of view, the XForms functions are (at
least for us) an *extension* to the base COM library.

Now you could say that this is our problem; just because our code requires a
namespace prefix on any function libraries that are not part of the core
XPath library, doesn't mean that the XForms spec should be changed. But
there is a bigger issue here, which will concern anyone who wants to
implement an XForms processor using as many standard components as possible.
Our approach is that to build an XForms processor you should:

- take a *standard* DOM3 XPath processor
- add a *standard* DOM 3 Document handler
- add a *standard* DOM 3 Event handler
- add your specific function library for XForms, but add it in a *standard*
way to the XPath processor

... and so on, building up layer upon layer.

Of course these modules don't exist yet and we have had to write them
ourselves, but the approach is right, I believe. And as more and more of
these modules do exist, it should be possible to build applications from
components that originate from many different sources. At the moment the
XForms spec takes the almost polar opposite approach, and effectively says
that everyone who implements an XForms processor must also implement their
own XPath processor, so that they can parse the XForms-specific functions.
But then they still have to add a facility to connect to external libraries,
as allowed by the spec.

Our second reason for sticking with this approach (of using namespace
prefixes on functions) is not just that we are in good company (the guys at
X-Smiles have done the same) but also because XPath 2.0 is going the same
way [1]. Admittedly that spec is still being developed, but the general
pattern of 2.0 is that ALL functions and operators are namespace prefixed.
(Although there is the notion of a 'default function' namespace so that you
can abbreviate the invocations.)

So, it seems to me that if the XPath functions themselves are coming out of
the core, then we certainly shouldn't be thinking of putting XForms
functions back into it.

Note also that the functions and operators now stand alone, in a separate
spec [2] from the core of XPath 2.0. Taking the namespace prefix approach
would allow XForms to do the same, so allowing a new set of functions to be
created at a later date that use a different namespace to the current ones,
without having to rewrite the core spec. Admittedly for the small number of
functions we have this is not that big a deal, and many of those will be
unnecessary when XPath 2.0 is finalised.

[1] http://www.w3.org/TR/xpath20/
[2] http://www.w3.org/TR/xquery-operators/



Mark Birbeck
Co-author Professional XML,
and Professional XML Meta Data,
both by Wrox Press

Try our XForms plug-in for IE
at http://www.FormsPlayer.com/

Managing Director
x-port.net Ltd.
4 Pear Tree Court

E: Mark.Birbeck@x-port.net
T: +44 20 7689 9232
M: +44 7774 102 413
W: http://www.x-port.net/
Received on Tuesday, 26 November 2002 10:00:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:25:05 UTC