- 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