XML Processing Model WG

08 Jan 2009


See also: IRC log


Mohamed, Paul, Alex, Norm, Vojtech, Henry


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?

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


Accept minutes from the previous meeting?

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


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.


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

<alexmilowski> from: 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


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.


[End of minutes]

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