See also: IRC log
Date: 26 Feb 2009
<scribe> Meeting: 137
<scribe> Scribe: Norm
<scribe> ScribeNick: Norm
<scribe> Meeting: XML Processing Model WG
Date: 26 Feb 2009
<scribe> Agenda: http://www.w3.org/XML/XProc/2009/02/26-agenda
<scribe> Meeting: 137
<scribe> Chair: Norm
<scribe> Scribe: Norm
<scribe> ScribeNick: Norm
-> http://www.w3.org/XML/XProc/2009/02/26-agenda
Accepted.
-> http://www.w3.org/XML/XProc/2009/02/05-minutes
Accepted.
No regrets heard.
Looking forward, Norm is likely to give regrets for 19 Mar and 2 Apr, so maybe Henry can chair?
-> http://www.w3.org/XML/XProc/2008/11/cr-comments/
Vojtech: This happens in two parts, both when you're constructing a request and when you're processing a response.
We got your voicemail henry!
<ht> Sorry, hang on
Nope, ht, try again!
Some discussion
Alex: This is more complicated becuase there can be encodings and such in the header value.
Vojtech: Right. Do we ignore one, or merge them which would be too complicated, or what?
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.
... And if you specify a different charaset parameter
explicitly, then that can be a problem too.
... I think the right way to look at this is that the computed
values should match.
... We need to reword XC0020 to cover that case.
Norm: Two things: one is the logic for computing the content type, the other is what to do with the header values.
Alex: I think it's a potentially slippery slope, there are lots of things in HTTP that can be confusing.
Norm: Alex, can you take a stab at some prose to discuss this?
Alex: Absolutely.
<scribe> ACTION: Alex to describe how content type values are computed. [recorded in http://www.w3.org/2009/02/26-xproc-minutes.html#action01]
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.
Alex: Yes.
Accepted.
<scribe> ACTION: Norm to add text about the error case after we have wording from Alex [recorded in http://www.w3.org/2009/02/26-xproc-minutes.html#action02]
Norm: I couldn't find it in the minutes, but I think we decided to allow it, even if it's probably stupid.
Vojtech: Right.
Accepted.
Some discussion
Norm: Vojtech: you can do it any way. If you specify the multipart in the pipeline you can do this.
Alex: This is about the request, yes?
Vojtech: I think it's about both.
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.
Norm: We could also say that the content-type attribute should be the bare value without parameters.
Some more discussion about the value of the boundary attribute.
Alex: The boundary attribute is required. Eew.
Norm: I think removing it would force us back to Last Call.
Alex: So we can just say they have to be the same, and use XC0020.
Norm: Why not forbid it?
Alex: Because of the round-tripping case.
Norm: So the proposal I hear is that we say that if you specify them both, they MUST match.
Accepted.
Vojtech: So the remainder of the
question, when you parse the response, do you generate the
headers?
... I think you do generate them, but the values will always
match so it's ok.
Norm: Yes, I think you generate the headers.
Alex: This one is easy, you get back the content. 404 is just like any other response.
Norm: Yep.
Vojtech: I think so too.
Proposal: Close w/o action.
Accepted.
Alex: That seems like a nice to
have.
... I don't think it's something we need to do for V1.
Proposal: Not in V1.
Accepted.
Alex: Right now you get an error. The encoding parameter on p:http-request applies to all of the parts.
Some discussion
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.
Alex: Does the encoding serialization parameter apply to non-XML content.
Some argument about whether or not you can have non-XML *to* serialize.
Henry: We don't have to support this and I don't think that's a problem.
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.
... 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.
Vojtech: We say that the serialization options are provided to control serialization of any XML content.
<scribe> ACTION: Norm to fix the content model of c:body as it's reproduced in the spec [recorded in http://www.w3.org/2009/02/26-xproc-minutes.html#action03]
Alex: I think we still don't have the content type handling correct here.
Henry: There's no paragraph that
specifies what happens if the content type does not specify an
XML media type.
... What I said before was wrong, XML serialization is never
involved if the content type isn't an XML media type.
... We say the output will consist of "those characters" but
what we have to put on the wire is "those bytes"
To be continued.
None heard.
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/seralize/serialize/ Found Scribe: Norm Inferring ScribeNick: Norm Found ScribeNick: Norm Found Scribe: Norm Inferring ScribeNick: Norm Found ScribeNick: Norm Present: Norm Paul Vojtech Alex Mohamed Henry Agenda: http://www.w3.org/XML/XProc/2009/02/26-agenda Found Date: 26 Feb 2009 Guessing minutes URL: http://www.w3.org/2009/02/26-xproc-minutes.html People with action items: alex norm[End of scribe.perl diagnostic output]