W3C home > Mailing lists > Public > xproc-dev@w3.org > April 2010

Re: Viewing intermediate results

From: James Fuller <james.fuller.2007@gmail.com>
Date: Fri, 16 Apr 2010 17:52:04 +0200
Message-ID: <m2na0ad8ffe1004160852g22dc9216q5a730d93021fb97c@mail.gmail.com>
To: Wendell Piez <wapiez@mulberrytech.com>
Cc: xproc-dev@w3.org
On Fri, Apr 16, 2010 at 5:36 PM, Wendell Piez <wapiez@mulberrytech.com> wrote:
> Jim,
> At 11:18 AM 4/16/2010, James Fuller wrote:
>> p:log should help
>> http://www.w3.org/TR/xproc/#p.log
> Yes, thanks, and I was also pointed (off-list) to the very interesting
> thread at
> http://markmail.org/thread/a4vmdkmbagah4ydf#query:+page:1+mid:gajyfhhx5pcnftbi+state:results.
> In particular, and partly since I'm using oXygen (with its excellent support
> for allowing me to see stuff without writing it to disk), I'm intrigued by
> Geert's suggestion in this thread that simply declaring extra ports does the
> job: I expect that will be so for me.

the xproc processor (under dev, not ready for prime time yet) shows
all results at all stages when put into debug mode .... can't remember
if calabash has a commandline setting for explicitly showing documents
during processing ... I think it did (not on my regular machine at the
moment to test).

> In that case (lightbulb moment), I can simply use two different oXygen
> scenarios on the same pipeline: one that shows me intermediate results,
> another that doesn't. (And if I really want, a third can serialize things.)

yes, correct.

> This is interesting stuff. I guess it makes sense that when designing in
> XProc, the features of the calling environment bear largely on the tradeoffs
> in the available approaches.

yes, probably an extension function or step in there as well.

Received on Friday, 16 April 2010 15:52:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:03:06 UTC