Accept this agenda?

Happy New Year to all!

-> http://www.w3.org/XML/XProc/2010/01/07-agenda

Accepted.

Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2009/12/17-minutes

Next meeting: telcon, 14 Jan 2010?

Norm gives likely regrets; Henry to chair.

Henry gives regrets for 21 Jan

Vojtech gives regrets for 21 Jan

New Last Call WD published

-> http://www.w3.org/TR/xproc/

Norm: End of L/C is 2 Feb. I'll start a new comments list asap.

Creating MIME multipart documents with p:http-request

Norm attempts to recount his experience.

Norm: The HTTP ApacheClient library doesn't appear to produce what we expect.

Vojtech: We build the multipart data ourselves.

Norm: Ok, that was my other thought.
... Producing isn't to hard so maybe that's the right answer.

Henry: Library support for producing MIME multipart is somewhere between non-existant and broken

Alex: Content-disposition is the one we can't handle directly. That's an oversight on our part.
... Content-ID is for internal relationships. Content-disposition is for the receiver.
... I'm sending you a bunch of files, here are the names you should use; here are the dates you should use, etc.
... It's not a required header, so we could leave it out. But it makes sending a group of files really hard. The Content-disposition header is how the receiver knows what it should be.

Norm: You can construct the headers yourself, right?

Alex: No. We don't let you put headers in.

Norm: So you can't associate X-foo: with an arbitrary body part and that's ok?

Alex: I think it was the right choice when we did it.
... I think it's a very rational position to take, the multipart spec doesn't encourage additional headers on individual bodies.

-> http://www.w3.org/mid/28d56ece0912171510k4ce5e358g5a155bd7b0957a35@mail.gmail.com

Alex: We just missed one.
... We probably should have added a disposition attribute, but we just went back to last call.
... The receiver will just have to handle the fact that the sender doesn't provide filenames.

Norm: That clarifies things for me.

Vojtech: So what does content-disposition mean for the XProc processor itself?

Norm: Yeah, where do those headers go?

Alex: They fall on the floor.

Some discussion of how to deal with these.

Henry: I'd be happier with some form of extensible solution.

Some discussion of the modelling. The headers on c:multipart are for the multipart message.

Vojtech: If the attributes map to the headers, we should name them content-id, content-description, etc.

Alex: For additional headers, we'd have to have a story about how to create attributes for them.

Norm: I don't know if we should try to fix the general problem, or just deal with what we actually expect

Alex: We could add a disposition header today and leave adding a c:multipart-body to some future version.

Norm: Indeed. And if no one ever asks, we never have to do it.
... So our options appear to be: (1) do nothing, (2) add a disposition attribute, (3) invent a more complex but extensible story

<alexmilowski> section 6.1 of http://tools.ietf.org/html/rfc2387

Straw poll: (2) gets 4 votes, (3) gets 2.

scribe: (1) gets none.

Proposal: For V1, add a disposition attribute for specifying the content-disposition.
... to c:body

Henry/Vojtech: Do these make sense outside the multipart context?

Norm: I don't think it causes any harm to send the headers in the non-multipart case.

Alex: You can send any headers you want. I think the technical question is whether description and disposition set those headers.

Norm: I propose if you set the attribute, the header is sent, multipart or not.

Accepted. We'll add disposition.

Norm: Do we want to take up the question of renaming these attributes?

Henry: No, because it's unnecessarily verbose.

Norm: ok

<scribe> ACTION: Norm to produce a new WD reflecting the new attribute. [recorded in http://www.w3.org/2010/01/07-xproc-minutes.html#action01]

Comments on the latest draft?

Norm: A few on the list, I'll generate a new status page as I said, any comments from WG members at the moment?

Vojtech: Currently we say that we use the XSLT Match Pattern for things like Viewport, but we don't say what version.
... The processor doesn't know which XSLT version to use.

Henry: I'd rather not put this in user control. I think our earlier decision this was the intersection was small. We should encourage implementors to use XSLT 2.0 if they support it and use 1.0 otherwise.

Vojtech: You can say xpath-version is 2.0 in a pipeline, but you can't do the same thing with match patterns.

Henry: I'd prefer to say that the xpath-version switch controls the match patterns as well.

Vojtech: What about XSLT 3.7 and there's no corresponding XPath version.

Alex: That's for V2 or implementation defined features.
... In V2 we can add a new function if we really need to.

Vojtech: If you bind them together, then you can't break that in V2. So that seems risky.

Norm: Good point. In that case, I think I'd prefer to say that you can't test it in V1 and it's impl defined.

Test suite progress?

Norm: I don't think there's a lot to say.
... I haven't run against it recently.

Vojtech: Calumet is doing well.
... The multipart tests are also failing.

Some discussion of the fact that it's hard to generate identical results for the multipart tests.

Norm: If you think you pass, you're done. It may never be possible to get the test suite machinery to deal with those tests adequately.

Default processing model progress?

Henry: We've had some comments, but I haven't made any progress.
... Not likely to be ready for next week.

Any other business?

None heard.

Adjourned.