W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > February 2007

Parameters: let's keep it simple

From: Alessandro Vernet <avernet@orbeon.com>
Date: Wed, 28 Feb 2007 00:34:17 -0800
Message-ID: <4828ceec0702280034r397742e6j552523f7803b1576@mail.gmail.com>
To: public-xml-processing-model-wg <public-xml-processing-model-wg@w3.org>

After our discussion about parameters during the call last week, and
after reading Alex's elaborate reasoning [1], I feel increasingly
attracted by the status quo. And this because its simplicity. With one
condition though. But before we get into this, let's get some
inspiration from plain old command tools.

We have talked about having multiple classes of parameters. At some
point we had up to 3 classes, each used for different things, and
syntactically different. The drawback with one class seemed to be that
we couldn't have an XSLT parameter called initial-mode and at the same
time the value of stylesheet parameter which would be initial-mode.
With command line tools, there is only one class of parameters; and it
seems to work pretty well. For instance, you can both pass the "l"
option to "ls" (ls -l) and list a file called "l". It is no magic,
just a convention: adding a prefix in front of parameters in a given

We can do the same when we define the XSLT component. For instance, we
can say that the XSLT component take two parameters initial-mode and
initial-template, plus any parameter that starts with "param-"; any of
those parameter will be passed to the stylesheet without the "param-".
In code, this gives:

    <p:input port="source">...</p:input>
    <p:input port="stylesheet">...</p:input>
    <p:parameter name="initial-mode" value="..."/>
    <p:parameter name="param-initial-mode" value="..."/>

The same principle applies to inputs as well. Say you want to accept
parameter documents, in addition to parameter values. For instance in
the case of XSLT 2.0, where parameters can be documents. No problem,
we can define the XSLT 2.0 components to map inputs that start with
"param-" to parameters which name is equal to what follows "param-".

    <p:input port="source">...</p:input>
    <p:input port="stylesheet">...</p:input>
    <p:input port="param-employee">...</p:input>

Unlike the scheme where we introduce 2 classes of parameters by using
a different syntax (named elements, generic p:parameter, or
attributes), this extends quite nicely to the cases where we need more
than 2 classes.

Consider you want to create a component that exposes the functionality
of a tool like wget or curl. Maybe you will want to use parameters to
set HTTP headers, POST name/value request parameters, as well as other
parameters like which user name or password to use. Here you already
have 3 classes of parameters. But you can do all this with the simple
<p:parameter> construct we already have, by following the convention
of adding a prefix to parameter names. For instance:

    <p:parameter name="username" value="..."/>
    <p:parameter name="password" value="..."/>
    <p:parameter name="header-User-Agent" value="..."/>
    <p:parameter name="header-Authorization" value="..."/>
    <p:parameter name="post-firstname" value="..."/>
    <p:parameter name="post-lastname" value="..."/>

Assuming that we use a naming convention in standard components, and
encourage component authors to follow the same convention, my
preference is to keep to status quo. Again, provided we follow some
simple conventions, the construct we already have is both simple and
solves all the cases we have seen so far.


[1] http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Feb/0108.html
Orbeon Forms - Web 2.0 Forms for the Enterprise
Received on Wednesday, 28 February 2007 08:34:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:41 UTC