See also: IRC log
-> http://www.w3.org/XML/XProc/2015/09/23-agenda
Accepted.
-> http://www.w3.org/XML/XProc/2015/09/09-minutes
Accepted.
No regrets heard.
-> https://github.com/xproc/specification/issues/136#issuecomment-128004501
Jim: I did a draft a few months
ago; this is the result of comments from that review.
... I simplified to a single 'errors' port and I've tried to
simplify some other things.
Jim summarizes the proposal.
Norm: Do we want to allow steps that succeed to write to the error port.
Henry: The most obvious problem
it's trying to solve seems to be that I run a pipeline and I
don't get any output.
... In order to solve that problem, percolation is
necessary.
... In shell-land, if someone writes to STDERR you see it,
unless active steps have been take to redirect it.
Norm: the other problem to solve is to let steps produce diagnostic output *without* failing.
Norm attempts to summarize a plausible "percolating story"
Norm mumbles a bit about the distinction between loggers in the Java environment vs stderr in the unix shell.
Norm: steps send to the error port information they want the pipe to react to, they can log anything they want.
Henry: Putting the error information into the pipeline doesn't make a lot of sense.
Norm: But catching validation errors is common...
Henry: The idea that what comes
out on the error port is likely to be processed *by other
steps* is very unlikely.
... Going back to the logger example, the stuff that gets
logged is for humans or third party apps.
Murray: Except when it does.
Norm: I'm not sure I agree. I think processing stderr output is not uncommon.
Murray: You can use loggers and
try/catch and all the other methods you have to build your
pipeline.
... My concern about stderr is that any given step could call a
shell script, etc.
... How do I get those messages from stderr.
<ht> Good point
Murray: I could do all those
things probably better if I had another script and a try catch.
ETc.
... The point is, unless you write a lot of code to catch
stderr, you're not going to see it.
... If you could see the messages on the console, you might be
able to quickly figure out what went wrong.
... You're typically not going to design a pipeline to rely on
stderr.
Norm: What do you mean by capture? The human or the pipeline?
Murray: One or the other.
Norm: So I think you're supporting what Henry said earlier. Let it percolate up, but also be able to catchint.
s/chatcint/catch it/
Norm: I think that's consistent with what Jim proposed. I think we want to say that steps can write to stderr without failing.
Jim: What are the constraints on what is produced?
Norm: I think a sequence of c:error elements with some required attributes and an ANY body
Jim: If a try catch fails and then gets handled, do we still report to the errors report the failure.
Norm: I think the catch gets all
the error output and it doesn't get passed along unless the
catch does so.
... Jim, do you want to try to put this in the spec.
... How do we make the percolation go through compound
steps.
Jim/Henry: I think it's implicit.
Norm: Does that mean we're taking
the name "errors" away from people?
... I suppose we could call it #errors so it's not declarable
by mortals.
Jim: I think we can just take that name.
Henry: As long as we call it
something other than "errors", it's probably ok. Call it
"stderr" for the time being.
... On the basis that it's a name that won't have been
used.
Norm attempts to summarize the proposal.
Murray: Can we separate stderr
from one step. Say I've got step 12 that's 7 layers down.
... can I redirect that.
Norm: Yes, by grabbing it like any ordinary port.
Murray: Can I 'tee' it.
Norm: Uhm...that might require
some work.
... I'll add that to the issue.
Norm hypothisizes about using p:error to do the tee.
None heard.