- From: James Fuller <james.fuller.2007@gmail.com>
- Date: Thu, 21 Feb 2008 16:58:32 +0100
- To: "Norman Walsh" <ndw@nwalsh.com>
- Cc: public-xml-processing-model-comments@w3.org
On Thu, Feb 21, 2008 at 4:47 PM, Norman Walsh <ndw@nwalsh.com> wrote: > / James Fuller <james.fuller.2007@gmail.com> was heard to say: > > | it makes sense if what u want is to have a log of what happened at > | that step and capture all input/output e.g. consider the trivial > | example log output I generate from a declare-step with a > | log="somefile.xml" attribute. > | > | <step name="mystep"> > | <input port="">some xml that came in</input> > | <output port="">xml output of the step</input> > | </step> > | > | I see this as a useful debugging output on <p:pipeline/>, <p:group/>, > | try/catch, etc ... > > I'm sorry, Jim, but I don't follow that example at all. I don't see *any* > log attribute or element there, so I'm not sure what you're getting at. I am not being clear take the following log attribute being set on a step, <p:identity name="mystep" log="test.log"/> might generate some trace/log information as xml <log> <step xproc:defaultname="!1:mystep" name="mystep"> <input port="">some xml that came in</input> <output port="">xml output of the step</input> </step> </log> > | keeping the log format XML I think is useful as > | well. > I don't think we want to say anything about the format, especially since > I don't want to attempt to solve the "how do you represent a sequence of > documents" question. fair enough point .... most of the issues that I am bringing up now have to do with some experience through implementation .... having an 'out of band' trace/log becomes very useful in debugging xproc pipelines ... just a little concerned that there are still a few 'cowpaths' that will eventually need paving in current xproc draft. cheers, Jim
Received on Thursday, 21 February 2008 15:58:55 UTC