- From: James Sulak <jsulak@gmail.com>
- Date: Sun, 24 May 2009 17:09:56 -0500
- To: Dave Pawson <dave.pawson@gmail.com>
- Cc: XProc Dev <xproc-dev@w3.org>
>From a cursory inspection, I see a few possibilities for importing
sets of options in xproc.
Most conveniently, the proposed configuration schema, which appears to
be able to set options. (http://exproc.org/proposed/schemas/). I like
this the best if it becomes widely implemented. Does calabash use it
now?
Second, you can define a set of name/value pairs in an external XML
document, and then use it to set variables:
<p:declare-step xmlns:p="http://www.w3.org/ns/xproc"
xmlns:wxp="http://www.wordsinboxes.com/xproc" name="pipeline">
<p:input port="source" primary="true" sequence="true">
<p:inline>
<root/>
</p:inline>
</p:input>
<p:input port="variables" sequence="true">
<p:inline>
<wxp:variable-set>
<wxp:variable name="new-name" value="hello"/>
</wxp:variable-set>
</p:inline>
</p:input>
<p:output port="result" primary="true" sequence="true"/>
<p:variable name="new-name"
select="(//wxp:variable[@name='new-name']/@value, 'goodbye')[1]">
<p:pipe port="variables" step="pipeline"/>
</p:variable>
<p:rename match="/*">
<p:with-option name="new-name" select="$new-name"/>
</p:rename>
</p:declare-step>
Note that I've used a sequence to define a default value for
$new-name. You could adapt the above to use a parameter input port if
you wanted.
There might be a more elegant way to do it, but I don't see it at the
moment. Anybody want to give their 2 cents? Would xi:including a
bunch of p:options into the pipeline work?
-James
On Sun, May 24, 2009 at 8:24 AM, Dave Pawson <dave.pawson@gmail.com> wrote:
> 2009/5/24 Norman Walsh <ndw@nwalsh.com>:
>> Dave Pawson <dave.pawson@gmail.com> writes:
>>
>>> http://www.dpawson.co.uk/nodesets/entries/090524.html
>>>
>>> Just my thoughts. I'd appreciate yours.
>>
>> My immediate thoughts, posted as a comment:
>>
>> XProc absolutely supports runtime options that can act like
>> properties and variables in ant and bash.
>
> As per xslt params/variables? So I could import them
> from an external file and use them?
>
>
>
>
> You can, with an
>> (existing) extension step generate a pipeline and then evaluate it,
>> but I really think you're making the whole process way more
>> complicated than it needs to be. I will (hopefully this weekend)
>> take a closer look at your ant setup and derive an equivalent XProc
>> pipeline.
>
> Possibly. If xproc is 'smarter' then great, I'm willing to learn.
>
>
>
>
>>
>> There's already a p:exec step in XProc 1.0, so I don't think that's
>> exactly out of scope.
>
> So I could run the Python script and obtain the exit code,
> hence terminate on failure?
>
>>
>> I don't think it would be unreasonable for p:http-request to
>> support FTP uploading, though I haven't tried to make that work in
>> XML Calabash. I'll put it on the list.
>
> Is that twisting http a bit?
> p:ftp seems a better name?
>
>
>>
>> I also don't see any problem with a px:zip step, though I'd want to
>> think carefully about how it should work. Ideally it would allow you
>> to both create new archives as well as update existing archives.
>
> The ant zip task seems pretty comprehensive to me?
> http://ant.apache.org/manual/CoreTasks/zip.html
>
>
>
>>
>> I remain convinced that most of what you want to do is right in
>> XProc's sweet spot. The parts that aren't are also entirely
>> reasonable, with a few extensions.
>
> Glad to have an experts view. Agreed the task may change
> when brought over to xproc.
>
>
>>
>> I don't mind using extensions. That will help the community learn
>> what additional steps should be in the V.next standard. That strikes
>> me as better than trying to put the kitchen sink in V1.0.
>
>
> +1, as per exslt.
>
>
> regards
>
>
>
>
> --
> Dave Pawson
> XSLT XSL-FO FAQ.
> Docbook FAQ.
> http://www.dpawson.co.uk
>
>
Received on Sunday, 24 May 2009 22:10:38 UTC