W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > January 2009

XProc Minutes 8 Jan 2008

From: Norman Walsh <ndw@nwalsh.com>
Date: Thu, 08 Jan 2009 12:09:41 -0500
To: public-xml-processing-model-wg@w3.org
Message-ID: <m2fxjtzpuy.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2009/01/08-minutes

[1]W3C

                                   - DRAFT -

                            XML Processing Model WG

08 Jan 2009

   [2]Agenda

   See also: [3]IRC log

Attendees

   Present
           Mohamed, Paul, Alex, Norm, Vojtech, Henry

   Regrets

   Chair
           Norm

   Scribe
           Norm

Contents

     * [4]Topics

         1. [5]Accept this agenda?
         2. [6]Accept minutes from the previous meeting?
         3. [7]Next meeting: telcon 15 Jan 2009?
         4. [8]004: base URI
         5. [9]010: Algorithm for step names
         6. [10]013: http-request is missing the realm
         7. [11]014: Return code from p:exec
         8. [12]Any other business?

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

   Considering which issues to discuss: 004 (again), 010, 013, 014, 015, 022,
   023, 035. I bet that'll take the whole hour.

  Accept this agenda?

   -> [13]http://www.w3.org/XML/XProc/2009/01/08-agenda

   Accepted.

  Accept minutes from the previous meeting?

   -> [14]http://www.w3.org/XML/XProc/2008/12/18-minutes

   Accepted.

  Next meeting: telcon 15 Jan 2009?

   Norm and Paul give regrets, Henry to chair

  004: Base URI

   Norm: Any new thoughts? Absent Richard, I don't expect to make any
   progress.

  010: Algorithm for step names

   Norm summarizes.

   Norm: I think we have two choices, pick another algorithm that works or
   punt.

   Vojtech: The invocations will get two different names, can we take
   advantage of that?
   ... If you import something, you always have to invoke it.

   Norm: Yes, but in the context of the top level pipeline, there are two
   steps with the same name.

   <ht> Is import order deterministic?

   Mohamed: Could we just use the URI of the document?

   Vojtech: I don't see the problem.

   Henry: Is import order deterministic?

   Norm: I think so, though I'm not sure we say that.

   Henry: In that case, I suggest !{importnumber}!{stepnumber}

   Alex: I was thinking the same thing.

   Vojtech: Importing makes the step types available, why does the pipeline
   element get imported?

   Norm: I see your point, but...

   Henry: But the use case is, there's an error, one of those anonymous steps
   generates an error. If you report "!1" but you imported several anonymous
   pipelines, how do you know which one "!1" is?
   ... What if I import two anonymous pipelines each of which has a step with
   the same name?

   Vojtech: That step is never visible outside the pipeline.

   Henry: This situation is no worse than the case where I import two
   libraries that have two steps with the same name.

   Norm: I'm satisfied that I was off in the weeds when I raised the issue.

   Henry: We're just back from vacation, let's leave this one and see if it
   really comes back to bite us.

   Norm: Ok, but I'm inclined to close it and let it be reopened by a new
   bug.

   Henry: Ok

   Norm: I propose we close this with no action.

   Accepted.

  013: http-request is missing the realm

   Norm attempts to explain the problem.

   <alexmilowski> The first time the client requests the document, no
   Authorization header is sent, so the server responds with:

     HTTP/1.1 401 Unauthorized
     WWW-Authenticate: Digest
     realm="testrealm@host.com",
     qop="auth,auth-int",
     nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
     opaque="5ccc069c403ebaf9f0171e9517f40e41"

   <alexmilowski> from: [15]http://tools.ietf.org/html/rfc2617

   Alex: You need the 401 for digest authentication and it includes
   everything you need.

   Norm: So we can close 013 w/o action.

  014: Return code from p:exec

   Henry: My experience was that you didn't automatically want to make the
   step fail if the subprocess failed.
   ... Subprocess failure is a complex process and it's not completely lined
   up acros different platforms.

   Norm: AFIACT, we have only two options, either add a new port or make the
   result port return a c:result with some indication of the return code and
   then the returned body.

   Some discussion of which is better: a new port or mangling the output of
   the result port.

   Norm: Is there anyone who wants to argue that we should ignore this
   oversight?

   None heard.

   Henry: I lived without it for several years.

   Alex: But w/o the return code, you don't know if the process failed.

   Vojtech: What about letting p:exec throw a dynamic error/

   Alex: The most significant part is about whether or not it succeeded.

   Norm: Yes, I don't think a non-zero return code is always an error.

   Straw poll: fix it or not fix it?

   Straw poll results: five to fix, one abstention.

   <alexmilowski> new port ! :)

   Norm: I see two options, a new result port or fiddle with what comes out
   of the result port.

   Henry: I'd be willing to consider treating this as a step error and
   putting the error code in the error port.

   Norm: In that case you'd never be able to get the non-error output in the
   case where a process used the RC for something other than error.

   <ht> HST: Yes, that's right, and I could live with that

   Vojtech: We could say that there's something on the error output port,
   even if it succeeds. And it always contains the return code.

   Norm: So there are four options: new port, fiddle the result, fiddle the
   error, throw a dynamic error

   Mohamed: I was thinking that there already is an error*s* port on p:exec.

   <ht> 'errors' is not the error port!

   Henry: I think it's important to remember the distinction between total
   failure: when that happens we get implementation defined errors on the
   error port in the p:catch (if there is one).
   ... and the case where the process runs to completion, producing STDOUT
   and/or STDERR and a return code.
   ... We could add another input parameter which is the result-code
   threshold, which defaults to zero.

   Norm: We could do that, but then your pipeline wouldn't be able to know
   what the result code *was*

   Henry: I was thinking we could do the result-code threshold in addition to
   the errors port.

   Straw poll: Four possibilities: new port (error-code), tweek the output on
   the result port, tweek the output on the errors port, throw a dynamic
   error.

   Paul: What are the downsides of a new port.

   Norm: It changes the signature, but I don't see any particular
   disadvantage.

   Henry: I do. We don't really have an easy way to deal with documents on
   multiple ports simultaneously.

   Vojtech: I don't mind a new port.

   Norm: Nor I, the step already has two output ports.

   Henry: It seems to me that it's part of the errors output, really. It's an
   out-of-band piece of information that goes with STDERR.

   Vojtech: Even if the program doesn't produce any error output, you always
   get an empty c:result

   Norm: Not if you say errors-is-xml.

   Vojtech: So in that case, you'd need to make errors a sequence.

   Norm: Or always put c:result on the errors output.

   Henry: I was going to suggest an option 'report-error-code' that would
   override some of the existing options.
   ... and always put a c:result on the errors port.

   Straw poll results: 4 for new port, one for fiddle result, one for fiddle
   errors

   Norm: Is there anyone who can't live with a new port?

   None heard.

   Henry: I'd like a result-threshold option.

   Norm: That seems fine to me.
   ... Do you have a name in mind?

   Henry: abort-threshold, fail-threshold, failure-threshold

   Norm: I guess I like failure-threshold

   Accepted.

   Henry: I'm going to say that none of this puts us at risk for a return to
   L/C because this is an optional step.

  Any other business?

   None heard.

   Adjourned.


   [End of minutes]

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

    Minutes formatted by David Booth's [16]scribe.perl version 1.133 ([17]CVS
    log)
    $Date: 2009/01/08 17:09:04 $

References

   Visible links
   1. http://www.w3.org/
   2. http://www.w3.org/XML/XProc/2009/01/08-agenda
   3. http://www.w3.org/2009/01/08-xproc-irc
   4. file:///projects/w3c/WWW/XML/XProc/2009/01/08-minutes.html#agenda
   5. file:///projects/w3c/WWW/XML/XProc/2009/01/08-minutes.html#item01
   6. file:///projects/w3c/WWW/XML/XProc/2009/01/08-minutes.html#item02
   7. file:///projects/w3c/WWW/XML/XProc/2009/01/08-minutes.html#item03
   8. file:///projects/w3c/WWW/XML/XProc/2009/01/08-minutes.html#item04
   9. file:///projects/w3c/WWW/XML/XProc/2009/01/08-minutes.html#item05
  10. file:///projects/w3c/WWW/XML/XProc/2009/01/08-minutes.html#item06
  11. file:///projects/w3c/WWW/XML/XProc/2009/01/08-minutes.html#item07
  12. file:///projects/w3c/WWW/XML/XProc/2009/01/08-minutes.html#item08
  13. http://www.w3.org/XML/XProc/2009/01/08-agenda
  14. http://www.w3.org/XML/XProc/2008/12/18-minutes
  15. http://tools.ietf.org/html/rfc2617
  16. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
  17. http://dev.w3.org/cvsweb/2002/scribe/

Received on Thursday, 8 January 2009 17:10:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 8 January 2009 17:10:23 GMT