- From: James Fuller <james.fuller.2007@gmail.com>
- Date: Sun, 7 Dec 2008 17:15:54 +0100
- To: "James Sulak" <jsulak@gmail.com>
- Cc: "Dave Pawson" <dave.pawson@gmail.com>, xproc-dev <xproc-dev@w3.org>
I think the confusion is conflating binding which happens within the processor to writing to stdout ... also there a few 'default' conditions within XProc which takes getting used too, but I think after a few days people will appreciate the 'power user' aspect to this. in a simple pipeline the steps are; a) stdin becomes default source for the top level primary source input b) steps process, with resulting output naturally binding to the input of following stpes c) final result output is default delivered to stdout commandline switches can control what gets delivered to top level primary input, as well as define a uri for what happens to the final result (like serialize to a uri). In any event, I think the fix for this is putting or repeating (or putting in a link) of the existing XProc text on this closer to the initial examples so people don't have to hunt around the entire XProc spec to understand that there is no p:result-document brother to p:document. cheers, Jim Fuller On Sun, Dec 7, 2008 at 5:06 PM, James Sulak <jsulak@gmail.com> wrote: > I agree with Dave that his way seems more logical on its face, but I > think I understand why it was done the way it was (somebody who > actually knows might want to pitch in). I suppose it's analogous to > XSLT, where you can define input and output documents explicitly in > your transform by using document() and <xsl:result-document />, but > most of the time, you don't, since not doing it makes your transform > more portable. > > If you look at it that way, leaving the job of binding the output of a > pipeline to it's caller makes sense. Although I agree, it would be > nice to have an easy way to do it within the pipeline. > > -James > > On Sun, Dec 7, 2008 at 9:32 AM, James Fuller > <james.fuller.2007@gmail.com> wrote: >> >> On Sun, Dec 7, 2008 at 4:23 PM, Dave Pawson <dave.pawson@gmail.com> wrote: >>> >>> 2008/12/7 James Fuller <james.fuller.2007@gmail.com>: >>>> checkout >>>> >>>> http://www.w3.org/XML/XProc/docs/langspec.html#ex1 >>>> >>>> is a good example of p:output getting bound .... the logic especially >>>> starts making sense in multi branch xproc. >>> >>> >>> >>> <p:output port="result"> >>> <p:pipe step="validated" port="result"/> >>> </p:output> >>> >>> >>> That makes sense (to some extent) >>> For the overall pipleline, take the output from the result port of the >>> validated step. >>> >>> No problem. >>> >>> So, If I understand this... >>> >>> p:input wrapper >>> p:document tells it where to take input from >>> >>> p:output wrapper >>> p:document tells it where to get output from >>> >>> Which written like that seems daft IMHO. >>> >>> p:output wrapper >>> p:document tells it where to put output >>> >>> is a more logical user view IMHO. >>> >>> >>> In summary, for an atomic step >>> I can't say, within the pipeline, where to >>> get input from, and where to put output to? >>> I have to use defaults+the implementation params? >> >> thats not the case, u *can* say from within your pipeline, using for >> example a p:store step >> >> or you can resort to defining output binding uri from a commandline switch >> >> to be more verbose and explicit you could use p:load step instead of >> binding document to a port on your pipeline step. >> >> ps: I think you are looking for some sugar here ... which I agree >> would be useful. >> >> hth, Jim Fuller >> >>> >>> >>> Is that roughly right Jim? >>> >>> >>> regards >>> >>> >>> -- >>> Dave Pawson >>> XSLT XSL-FO FAQ. >>> Docbook FAQ. >>> http://www.dpawson.co.uk >>> >>> >> >> >
Received on Sunday, 7 December 2008 16:16:35 UTC