W3C

- DRAFT -

XML Processing Model WG

Meeting 137, 26 Feb 2009

Agenda

See also: IRC log

Attendees

Present
Norm, Paul, Vojtech, Alex, Mohamed, Henry
Regrets
Chair
Norm
Scribe
Norm

Contents


Accept this agenda?

-> http://www.w3.org/XML/XProc/2009/02/26-agenda

Accepted.

Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2009/02/05-minutes

Accepted.

Next meeting: telcon 5 Mar 2009?

No regrets heard.

Looking forward, Norm is likely to give regrets for 19 Mar and 2 Apr, so maybe Henry can chair?

Review of CR comments

-> http://www.w3.org/XML/XProc/2008/11/cr-comments/

089: conflicting content-type for body parts

Vojtech: This happens in two parts, both when you're constructing a request and when you're processing a response.

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]

090 p:hash and xml:base

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.

091: duplication of information in c:multipart

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.

092: p:http-request error content

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.

093: p:http-request: status message

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.

094: p:http-request content-type and encoding

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.

Any other business?

None heard.

Summary of Action Items

[NEW] ACTION: Alex to describe how content type values are computed. [recorded in http://www.w3.org/2009/02/26-xproc-minutes.html#action01]
[NEW] 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]
[NEW] 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]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2009/03/11 15:16:54 $