Accept this agenda?

-> http://www.w3.org/XML/XProc/2015/09/23-agenda

Accepted.

Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2015/09/09-minutes

Accepted.

Next meeting, 7 October 2015 (skipping 30 September)

No regrets heard.

Jim's revised proposal for an error port

-> 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.

Any other business?

None heard.