See also: IRC log
Norm gives likely regrets
Henry to chair if Norm sends an agenda in time
Rui gives regrets for 12 June
Andrew gives regrets for 12, 19 June
Norm: I think the thrust here is that we should be more explicit in all our steps
Henry: If it is the case that there's a majority case, then we could document that and only document exceptions
<scribe> ACTION: Norm to incorporate the suggestion to clarify the types of nodes matched by the steps into the next draft [recorded in http://www.w3.org/2008/06/05-xproc-minutes.html#action01]
Some discussion of (public-)email@example.com list; action on Henry ongoing
Vojtech: We should align error codes for matched nodes of the wrong type.
Norm: So a single error code for "you got the node type wrong"?
Vojtech: Or one for each kind of error.
Norm: I think that's a good idea.
Henry: We could have errors for text-node-not-allowed, element-node-not-allowed, etc.
Norm: Ok, I agree that's more informative.
Proposal: Replace random dynamic errors for this case with a set of five, one for each node type.
<scribe> ACTION: Norm to replace the random dynamic errors with the five so agreed [recorded in http://www.w3.org/2008/06/05-xproc-minutes.html#action02]
Wait until Mohamed is present.
Vojech: I think it's about the same prefix that we're using for built-in steps and extension steps.
Norm: Right. I'll fix that.
<scribe> ACTION: Norm to fix the patterns so that they don't have the same prefix in 4.7 and 4.8 [recorded in http://www.w3.org/2008/06/05-xproc-minutes.html#action03]
MoZ, is that what you wanted for the pfx:atomic-step comment?
Vojtech: A couple of points; first, one of the examples is still using c:http-request/c:http-request.
Norm: Ok, that's a bug.
<MoZ> Norm, sorry I just joined so I don't have access to IRC history, I'll take a look to the minutes after the telcon
Vojtech: In Section 126.96.36.199
there's an attribute @detailed which if it's set to false, it's
not clear what the step should generate.
... I think that if detailed=false, the c:response is not generated.
<scribe> ACTION: Alex to investigate [recorded in http://www.w3.org/2008/06/05-xproc-minutes.html#action04]
Vojtech: And then there's the question of what to do if the response is a multipart response where there are nested multiparts.
Norm: It's not immediately clear that that makes sense for us, but we should investigate.
<scribe> ACTION: Alex to investigate [recorded in http://www.w3.org/2008/06/05-xproc-minutes.html#action05]
Vojtech: Two more things.
... In Section 188.8.131.52 there are two conditions: if the content-type is XML or the encoding is base64 or not.
... Then different things can happen, but it seems to me that if the content-type is XML and encoding is base64 then the result is unspecified.
Norm: I think the right thing is decode it and parse it, but we should say that.
<scribe> ACTION: Alex to fix. [recorded in http://www.w3.org/2008/06/05-xproc-minutes.html#action06]
Vojtech: The last one is more of
a question, in 184.108.40.206 there's a note about text/html
... that says it'll be base64 encoded. But earlier it says that text types aren't encoded that way.
... So I wonder what the right answer is.
Norm: Yeah, that does seem strange. I'd have expected the text to just be escaped markup.