- From: Paul Tyson <phtyson@sbcglobal.net>
- Date: Mon, 11 Nov 2013 18:56:47 -0600
- To: "Toman, Vojtech" <vojtech.toman@emc.com>
- Cc: xproc-dev@w3.org
Hi Vojtech, (I assume you meant to reply to list.) On Mon, 2013-11-11 at 03:16 -0500, Toman, Vojtech wrote: > Hi Paul, > > You cannot do this with standard XProc out of the box, but you can get close by using p:viewport and the eval step (not part of XProc 1.0, but most XProc implementations provide some variant of it as an extension). > > Given the input document: > > <html xmlns="http://www.w3.org/1999/xhtml"> > <head><title>Title</title></head> > <body> > <my:query-and-transform> > <!-- options for this content chunk --> > </my:query-and-format> > <my:query-and-transform> > <!-- options for this content chunk --> > </my:query-and-transform> > </body> > </html> > > You might be able to do something like this: > > <p:pipeline xmlns:my="... "> > <p:viewport match="my:query-and-transform"> > <!-- ...apply the eval step to the embedded pipeline... --> > </p:viewport> > </p:pipeline> > Yes, that would be one workaround where p:eval is supported. I originally implemented a p:viewport version of a template using id values in the input document to indicate replaceable components. But after extending the viewport invocation a few times to keep up with changes in the template, it occurred to me that a better abstraction would simplify and improve the whole thing. I would still like the Xproc standard-writers to consider whether p:replace-pipeline should be included among the v2 standard steps. And I ask implementors if they see any big problem implementing this sort of thing. Regards, --Paul > Regards, > Vojtech > > -- > Vojtech Toman > Consultant Software Engineer > EMC | Information Intelligence Group > vojtech.toman@emc.com > http://developer.emc.com/xmltech > > > -----Original Message----- > > From: Paul Tyson [mailto:phtyson@sbcglobal.net] > > Sent: Saturday, November 09, 2013 3:51 PM > > To: Geert Josten > > Cc: xproc-dev@w3.org > > Subject: RE: embedded pipelines > > > > Hi Geert, > > > > Thanks for the pointers. I looked at > > http://www.w3.org/TR/xproc-template/, and it is sort of what I have in > > mind. However, I want to put entire pipelines in the template, not just > > XPath expressions, as provided by p:template. > > > > I cannot find any documentation for p:document-template in current > > Calabash documentation. I only see references to it in mailing list > > archive. It might be what I'm looking for. > > > > For example: > > > > <p:declare-step type="my:query-and-transform"> > > <p:option name="query-text"/> > > <p:option name="transform-spec"/> > > <!-- everything needed to connect to data source, run the query, and > > transform the results --> > > <!-- these sorts of pipelines could be defined in any of > > several different ways, as appropriate for the application --> > > </p:declare-step> > > > > <px:replace-pipeline> > > <p:input port="source"> > > <p:inline> > > <html xmlns="http://www.w3.org/1999/xhtml"> > > <head><title>Title</title></head> > > <body> > > <my:query-and-transform> > > <!-- options for this content chunk --> > > </my:query-and-format> > > <my:query-and-transform> > > <!-- options for this content chunk --> > > </my:query-and-transform> > > </body> > > </html> > > </p:inline> > > </p:input> > > </px:replace-pipeline> > > > > The effect of px:replace-pipeline (analagous to p:replace and > > p:replace-string) would be to transform the input document by replacing > > the embedded pipelines with their result documents. > > > > Note that the embedded pipelines could themselves have templates as > > input documents, allowing construction of template trees with very > > flexible run-time behavior controlled by parameter inputs. > > > > Regards, > > --Paul > > > > On Sat, 2013-11-09 at 14:22 +0100, Geert Josten wrote: > > > Hi Paul, > > > > > > Could you give a small example? > > > > > > It does sound like related to p:document-template and p:template, but > > > not sure if those extensions from XMLCalabash are still working, and > > supported.. > > > > > > Cheres, > > > Geert > > > > > > > -----Oorspronkelijk bericht----- > > > > Van: Paul Tyson [mailto:phtyson@sbcglobal.net] > > > > Verzonden: zaterdag 9 november 2013 4:32 > > > > Aan: xproc-dev@w3.org > > > > Onderwerp: embedded pipelines > > > > > > > > I don't know if this is in the Xproc standard (some parts are still > > > > a mystery to me), or if it has been implemented anywhere, but I > > > > wanted to put it out for comment. > > > > > > > > It would sometimes be convenient to embed pipeline steps in a > > > > (non-xproc) XML document, and then perform an xproc step on the > > > > document with the effect of replacing all the embedded pipelines > > > > with their results. The input document would serve as a template, > > > > with replaceable content specified by the pipeline steps. > > > > > > > > This would work like p:replace, except that the invocation would > > not > > > > specify what parts of the input document to work on or what to do > > > > with > > > > them: the "match" expression would be fixed to select all pipeline > > > > steps in the input, and the "replacement" document would be the > > > > result of evaluating each pipeline. The outer pipeline author and > > > > the template authors would have to arrange for the embedded steps > > > > and all resources to be known and available in the processing > > context. > > > > > > > > For example, well-formed xhtml or xsl-fo documents could contain > > > > pipeline steps that would expand to the intended content based on > > > > parameter inputs. This approach would lend itself to easier > > > > analysis, documentation, and maintenance than other popular > > > > templating mechanisms. > > > > > > > > This is a similar concept to the "simplified" XSLT templates, by > > > > which any XML document can be treated as an XSLT stylesheet, with > > > > restrictions on the xslt features that can be included. > > > > > > > > If others think this might be useful, consider adding it to the > > > > requirements for Xproc v2. > > > > > > > > Regards, > > > > --Paul > > > > > > > > > > > >
Received on Tuesday, 12 November 2013 00:57:16 UTC