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