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

RE: A parameters alternative

From: <vojtech.toman@emc.com>
Date: Thu, 9 Feb 2012 06:32:13 -0500
To: <public-xml-processing-model-wg@w3.org>
Message-ID: <3799D0FD120AD940B731A37E36DAF3FE341A8093A4@MX20A.corp.emc.com>
> Suppose we said that parameters were named collections of key/value
> pairs.
> The XProc context includes by default two such named collections:
>   p:global - initialized by some implementation-defined mechanism to
> contain
>              all the parameters passed to the pipeline by the user.
>   p:none   - initialized to be empty
> Implementations may provide a mechanism to create other named
> collections.
> We update p:parameters so that it adds/replaces keys to the collection
> it names.
> We remove parameter input ports in favor of a parameters option that
> takes a list of named collections. If no parameters option is
> specified, p:global is assumed.
> If we add types to options, we can make "parameters" a special type.

An interesting idea. If I understand it correctly, the p:global collection sort of replaces the primary parameter input of the owner pipeline. But how would that work with recursive/nested pipelines where you may want to pass different parameters to the pipeline? Or is p:global really global, so that you can use it, for instance, as a repository for global variables?

I think the final solution should make it easy to:
- pass a combination of two or more named collections to a step
- pass an extension (by constructing additional parameters manually in the pipeline) of a named collection to a step
- override parameters in a named collection

Is your idea that p:parameters would somehow be able to do this? That might be possible, but I wonder what the verbosity/annoyance factor of such an approach would be. Using p:parameters might disrupt the original processing sequence and force the pipeline author to use more p:pipe bindings.

Ideally, simple tasks, such as passing a single parameter to p:xslt, should be one (or two to three at worst) liners.


Vojtech Toman
Consultant Software Engineer
EMC | Information Intelligence Group
Received on Thursday, 9 February 2012 11:34:10 UTC

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