Re: Parameters, Manifests, and Use Case 5.6

On 10/12/06, Alex Milowski <> wrote:
> I don't see that we *need* computed paramters in version 1.0 to support
> this use case.


We use both inputs and parameters to feed data to components. The main
difference between inputs and parameters is in the type of the data:
XML for inputs, simple strings for parameters.

If we didn't have parameters in XProc, p:save would maybe be used this way:

<p:step name="save" kind="p:save">
    <p:input port="href">
    <p:input port="document" step="..." source="..."/>

But since we do have parameters, instead of feeding the URL through a
document, it makes more sense to use a parameter:

<p:step name="save" kind="p:save">
    <p:parameter name="href" value="file:///tmp/saved-file.xml"/>
    <p:input port="document" step="..." source="..."/>

In general, components will use parameters instead of inputs for
simple string. Someone will add a "character encoding" parameter to
the "save" component. A component returning the current time will take
"time zone" parameter. A component returning in which groups a user is
will take a "username" parameter.

But in all those cases, it is not because data is fed to a component
through a parameter rather than an input that it is less likely that
will need that parameter to be computed in a given pipeline.

Not having computed parameters is a severe restriction. It means that
when you create a component, you won't be able to use parameters in
the cases when you are likely to need those parameters to be computed.
Even worse: someone will design components and use parameters because
they think what they are fairly static, but you will need those
parameters to be computed, which will make the components unusable.

IMHO, the only reasonable alternatives are either not to have
parameters at all in the language and always inputs (which we seem to
have ruled out early on), or to have computed parameters.

Blog (XML, Web apps, Open Source):

Received on Thursday, 19 October 2006 01:11:15 UTC