Re: The first five minutes ... a thought experiment (long)

OK.  I'm curious.

Personally, I don't use p:pipeline because I've found that the moment
I need to do something a bit more complex, I have to switch to use
p:declare-step.  Also, the moment I want to make it a callable step
within a larger pipeline, I have to switch to p:declare-step.  So, I
just start with p:declare-step now.

On Wed, Feb 19, 2014 at 7:49 AM, Geert J. <geert.josten@dayon.nl> wrote:
> A lot has been said, still need to read up most unfortunately. But just a
> short reply on the example. My first stab at XProc (if I hadn't taken the
> unorthodox approach that I did, building my ebook proc) would have been:
>
> <p:pipeline>
>         <p:load href="myinput.xml"/>
>         <p:xslt href="mytransform.xsl"/>
>         <p:store href="myoutput.xml"/>
> </p:pipeline>

First, why not:

<p:pipeline>
   <p:xslt>
      <p:input port="stylesheet"><p:document href="mytransform.xsl"/></p:input>
   </p:xslt>
</p:pipeline>

and then you bind on the command-line:

   calabash -i source=myinput.xml -o result=myoutput.xml mypipeline.xpl

?

Second, here's the p:declare-step version:

<p:declare-step>
   <p:input port="source" primary="true"/>
   <p:output port="result" primary="true"/>
   <p:xslt>
      <p:input port="stylesheet"><p:document href="mytransform.xsl"/></p:input>
   </p:xslt>
</p:declare-step>

If you needed parameters, you'd have to add that port now but in V2 it
will happen differently.

>
> Which resembles Cocoon sitemap approach a lot. And anyone used to Cocoon
> sitemaps knows how easy it is to tie Cocoon pipes to each other, where in
> XProc it involves lots of verbose syntax to point to specific step ports
> that need to be in scope as well..

I don't find port binding that verbose and there are a bunch of
features packed in there for providing a great deal of flexibility in
building the input.  Meanwhile, we could make the simple case much
easier in V2 and we should consider doing so.

>
> XProc doesn't do that bad though. The only thing lacking here is the href
> on p:xslt. If that were present, you could easily chain lots of xslt's as
> well, by simply repeating the p:xslt:
>
> <p:pipeline>
>         <p:load href="myinput.xml"/>
>         <p:xslt href="mytransform.xsl"/>
>         <p:xslt href="mytransform2.xsl"/>
>         <p:xslt href="mytransform3.xsl"/>
>         <p:store href="myoutput.xml"/>
> </p:pipeline>

Again, this is more of the same.  I don't quite understand why you
don't use the ports that come with p:pipeline by default (there is
already a "source" and "result" port).

-- 
--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics

Received on Thursday, 20 February 2014 12:01:22 UTC