XProc Minutes 23 September 2015

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

[1]W3C

                                - DRAFT -

                         XML Processing Model WG

Meeting 278, 23 Sep 2015

   See also: [2]IRC log

Attendees

   Present

   Regrets

   Chair
           Norm

   Scribe
           Norm

Contents

     * [3]Topics

         1. [4]Accept this agenda?
         2. [5]Accept minutes from the previous meeting?
         3. [6]Next meeting, 7 October 2015 (skipping 30 September)
         4. [7]Jim's revised proposal for an error port
         5. [8]Any other business?

     * [9]Summary of Action Items

   --------------------------------------------------------------------------

  Accept this agenda?

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

   Accepted.

  Accept minutes from the previous meeting?

   -> [11]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

   ->
   [12]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.

Summary of Action Items

   [End of minutes]

   --------------------------------------------------------------------------

    Minutes formatted by David Booth's [13]scribe.perl version 1.140 ([14]CVS
    log)
    $Date: 2015/09/23 14:52:59 $

References

   1. http://www.w3.org/
   2. http://www.w3.org/2015/09/23-xproc-irc
   3. http://www.w3.org/XML/XProc/2015/09/23-minutes.html#agenda
   4. http://www.w3.org/XML/XProc/2015/09/23-minutes.html#item01
   5. http://www.w3.org/XML/XProc/2015/09/23-minutes.html#item02
   6. http://www.w3.org/XML/XProc/2015/09/23-minutes.html#item03
   7. http://www.w3.org/XML/XProc/2015/09/23-minutes.html#item04
   8. http://www.w3.org/XML/XProc/2015/09/23-minutes.html#item05
   9. http://www.w3.org/XML/XProc/2015/09/23-minutes.html#ActionSummary
  10. http://www.w3.org/XML/XProc/2015/09/23-agenda
  11. http://www.w3.org/XML/XProc/2015/09/09-minutes
  12. https://github.com/xproc/specification/issues/136#issuecomment-128004501
  13. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
  14. http://dev.w3.org/cvsweb/2002/scribe/