IRC log of xproc on 2009-02-26

Timestamps are in UTC.

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