- From: Jeni Tennison <jeni@jenitennison.com>
- Date: Sat, 14 Oct 2006 11:13:05 +0200
- To: public-xml-processing-model-wg@w3.org
Hi, Norman Walsh wrote: > / Alex Milowski <alex@milowski.org> was heard to say: > | What I found interesting was Jeni's examples of computing parameter > | values from different parameters and not inputs. They didn't actually > | get values from inputs but instead just choose between two parameter > | values using some expression. > | > | Maybe we could address that issue and remove the need for expressions > | to handle that case? Then we can push computed parameters on inputs > | to a future version. > > We could allow parameters to have a select expression but mandate in > V1 that the context was null. That would allow computation of one > parameter from others and it would leave the door open for something > else in the future. I would regard this as an absolute minimum, but not sufficient to enable me to do the complex XML processing for which I need XProc. In the kind of XML processing I do, it's incredibly useful to configure the process using an XML document. Using XML for config files gives me structured configuration, an obvious means of having different configurations for a process, enables me to generate config files automatically, enables me to process config files to generate documentation and so on and on. Config files are most useful when you have complex processing, so simplified use cases are rarely compelling, but to give you an idea, I might have config.xml: <config> ... <manifest href="manifest.xml" element="resources" /> ... </config> and supply it to the 'config' port of my:create-manifest. The attributes on the <manifest> element are used to configure the creation of the manifest and the location to which it's saved. <p:pipeline name="my:create-manifest"> <p:declare-input port="document" /> <p:declare-input port="config" /> ... <p:for-each name="create-svgs"> <p:declare-input port="document" source="document" /> <p:declare-output port="result" ... /> ... </p:for-each> <p:step name="agg" type="p:aggregate"> <p:input port="documents" step="create-svgs" source="result" /> <p:parameter name="wrapper" source="config" select="/config/manifest/@element" /> </p:step> <p:step name="save" type="p:save"> <p:input port="document" step="agg" source="result" /> <p:parameter name="href" source="config" select="/config/manifest/@href" /> </p:step> ... </p:pipeline> If I can't set parameters based on information in an XML document, then I can't use a config file as an input to the process. Instead, I have to dynamically generate the pipeline, and run that. This is both much more complicated for me as a user (code to generate code always is), and limits my choice of pipeline implementations to those that offer a "execute-pipeline" component. We need computed parameters in V1. Cheers, Jeni -- Jeni Tennison http://www.jenitennison.com
Received on Saturday, 14 October 2006 09:13:16 UTC