15:57:13 RRSAgent has joined #xproc 15:57:13 logging to http://www.w3.org/2009/02/26-xproc-irc 15:57:17 Meeting: XML Processing Model WG 15:57:19 Date: 26 Feb 2009 15:57:21 Agenda: http://www.w3.org/XML/XProc/2009/02/26-agenda 15:57:23 Meeting: 137 15:57:25 Chair: Norm 15:57:27 Scribe: Norm 15:57:29 ScribeNick: Norm 15:57:31 Meeting: XML Processing Model WG 15:57:33 Date: 26 Feb 2009 15:57:35 Agenda: http://www.w3.org/XML/XProc/2009/02/26-agenda 15:57:37 Meeting: 137 15:57:39 Chair: Norm 15:57:41 Scribe: Norm 15:57:43 ScribeNick: Norm 15:57:47 Zakim, this will be xproc 15:57:47 ok, Norm; I see XML_PMWG()11:00AM scheduled to start in 3 minutes 16:00:29 XML_PMWG()11:00AM has now started 16:00:36 +Norm 16:00:44 +[ArborText] 16:01:25 +Vojtech 16:01:48 alexmilowski has joined #xproc 16:02:30 MoZ has joined #xproc 16:02:34 +Alex_Milowski 16:03:06 Zakim, who's on the call? 16:03:06 On the phone I see Norm, PGrosso, Vojtech, Alex_Milowski 16:03:22 Zakim, what is the code ? 16:03:25 the conference code is 97762 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), MoZ 16:04:01 +MoZ 16:04:30 Present: Norm, Paul, Vojtech, Alex, Mohamed 16:04:48 Topic: Accept this agenda? 16:04:48 -> http://www.w3.org/XML/XProc/2009/02/26-agenda 16:04:53 Accepted. 16:05:00 Topic: Accept minutes from the previous meeting? 16:05:00 -> http://www.w3.org/XML/XProc/2009/02/05-minutes 16:05:07 Accepted. 16:05:15 Topic: Next meeting: telcon 5 Mar 2009? 16:05:31 No regrets heard. 16:05:52 Looking forward, Norm is likely to give regrets for 19 Mar and 2 Apr, so maybe Henry can chair? 16:06:17 Topic: Review of CR comments 16:06:24 -> http://www.w3.org/XML/XProc/2008/11/cr-comments/ 16:06:51 Topic: 089: conflicting content-type for body parts 16:07:22 zakim, please call ht-781 16:07:22 ok, ht; the call is being made 16:07:24 +Ht 16:07:50 Vojtech: This happens in two parts, both when you're constructing a request and when you're processing a response. 16:08:04 We got your voicemail henry! 16:08:14 Sorry, hang on 16:08:34 zakim, please disconnect ht 16:08:34 Ht is being disconnected 16:08:36 -Ht 16:09:09 zakim, please call ht-781 16:09:09 ok, ht; the call is being made 16:09:10 +Ht 16:09:17 Nope, ht, try again! 16:09:20 zakim, please disconnect ht 16:09:20 Ht is being disconnected 16:09:21 -Ht 16:09:52 zakim, please call ht-781 16:09:52 ok, ht; the call is being made 16:09:53 +Ht 16:10:43 Present: Norm, Paul, Vojtech, Alex, Mohamed, Henry 16:11:12 Some discussion 16:11:58 Alex: This is more complicated becuase there can be encodings and such in the header value. 16:12:10 Vojtech: Right. Do we ignore one, or merge them which would be too complicated, or what? 16:12:46 Alex: We do have encoding, and encoding is going to effect the content types of each of the bodies sent. So you should have a charset parameter on the content types. 16:13:47 ...And if you specify a different charaset parameter explicitly, then that can be a problem too. 16:14:32 Alex: I think the right way to look at this is that the computed values should match. 16:15:10 ...We need to reword XC0020 to cover that case. 16:16:05 Norm: Two things: one is the logic for computing the content type, the other is what to do with the header values. 16:17:45 Alex: I think it's a potentially slippery slope, there are lots of things in HTTP that can be confusing. 16:18:13 Norm: Alex, can you take a stab at some prose to discuss this? 16:18:18 Alex: Absolutely. 16:18:30 ACTION: Alex to describe how content type values are computed. 16:19:59 Norm: For the error, I thought I heard that if you specify both content-type on the body and an explicit c:header for the Content-Type header, then the computed value MUST exactly match the specified c:header value, or that's an error. 16:21:00 Alex: Yes. 16:21:14 Accepted. 16:21:33 ACTION: Norm to add text about the error case after we have wording from Alex 16:22:11 Topic: 090 p:hash and xml:base 16:22:28 Norm: I couldn't find it in the minutes, but I think we decided to allow it, even if it's probably stupid. 16:22:30 Vojtech: Right. 16:22:36 Accepted. 16:23:00 Topic: 091: duplication of information in c:multipart 16:24:26 Some discussion 16:25:10 Norm: Vojtech: you can do it any way. If you specify the multipart in the pipeline you can do this. 16:25:37 Alex: This is about the request, yes? 16:25:50 Vojtech: I think it's about both. 16:26:47 Alex: If you put a content-type attribute in there with a boundary parameter and specify a boundary, then that's going to be a conflict. I think we should say the same thing we said for 089 about computed values. 16:27:53 Norm: We could also say that the content-type attribute should be the bare value without parameters. 16:29:54 Some more discussion about the value of the boundary attribute. 16:31:17 Alex: The boundary attribute is required. Eew. 16:31:43 Norm: I think removing it would force us back to Last Call. 16:32:35 Alex: So we can just say they have to be the same, and use XC0020. 16:32:40 Norm: Why not forbid it? 16:32:47 Alex: Because of the round-tripping case. 16:34:27 Norm: So the proposal I hear is that we say that if you specify them both, they MUST match. 16:35:16 Accepted. 16:35:40 Vojtech: So the remainder of the question, when you parse the response, do you generate the headers? 16:36:19 ...I think you do generate them, but the values will always match so it's ok. 16:36:25 Norm: Yes, I think you generate the headers. 16:37:00 Topic: 092: p:http-request error content 16:37:24 Alex: This one is easy, you get back the content. 404 is just like any other response. 16:37:26 Norm: Yep. 16:37:29 Vojtech: I think so too. 16:37:38 Proposal: Close w/o action. 16:37:47 Accepted. 16:38:00 Topic: 093: p:http-request: status message 16:38:20 Alex: That seems like a nice to have. 16:39:04 ...I don't think it's something we need to do for V1. 16:39:35 Proposal: Not in V1. 16:39:43 Accepted. 16:39:58 Topic: 094: p:http-request content-type and encoding 16:41:22 Alex: Right now you get an error. The encoding parameter on p:http-request applies to all of the parts. 16:43:11 Some discussion 16:47:11 Henry observes that we can say "don't do this". The only way you could get here is fi you had two documents and wanted to encode them differently. 16:47:26 Alex: Does the encoding serialization parameter apply to non-XML content. 16:48:15 Some argument about whether or not you can have non-XML *to* seralize. 16:48:21 s/seralize/serialize/ 16:50:08 Henry: We don't have to support this and I don't think that's a problem. 16:51:26 Alex: If I have a c:body element with a content-type of text/plain and I have the word XProc in there and that's it and I don't specify any options, I'm going to get an error. 16:51:59 ...I'm going to run XML serialization on the text string XProc and the serialization code is going to have a fit becuase I didn't set a method. 16:54:47 Vojtech: We say that the serialization options are provided to control serialization of any XML content. 16:56:32 ACTION: Norm to fix the content model of c:body as it's reproduced in the spec 16:56:54 Alex: I think we still don't have the content type handling correct here. 16:58:28 Henry: There's no paragraph that specifies what happens if the content type does not specify an XML media type. 16:59:08 Henry: What I said before was wrong, XML serialization is never involved if the content type isn't an XML media type. 17:00:07 ...We say the output will consist of "those characters" but what we have to put on the wire is "those bytes" 17:01:44 To be continued. 17:01:49 Topic: Any other business? 17:01:54 None heard. 17:01:59 -PGrosso 17:02:02 -Norm 17:02:02 -Vojtech 17:02:03 -MoZ 17:02:03 -Alex_Milowski 17:02:06 RRSAgent, set logs world-visbile 17:02:09 RRSAgent, set logs world-visble 17:02:14 PGrosso has left #xproc 17:02:26 RRSAgent, set logs public 17:02:32 RRSAgent, draft minutes 17:02:32 I have made the request to generate http://www.w3.org/2009/02/26-xproc-minutes.html Norm 17:02:45 -Ht 17:02:47 XML_PMWG()11:00AM has ended 17:02:48 Attendees were Norm, PGrosso, Vojtech, Alex_Milowski, MoZ, Ht 18:37:07 Zakim has left #xproc