See also: IRC log
Date: 7 Jan 2010
<scribe> Meeting: 163
<scribe> Scribe: Norm
<scribe> ScribeNick: Norm
Happy New Year to all!
Norm gives likely regrets; Henry to chair.
Henry gives regrets for 21 Jan
Vojtech gives regrets for 21 Jan
Norm: End of L/C is 2 Feb. I'll start a new comments list asap.
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
... 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
... 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.
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
... 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.
<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]
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.
Norm: I don't think there's a lot
... I haven't run against it recently.
Vojtech: Calumet is doing
... 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.
Henry: We've had some comments,
but I haven't made any progress.
... Not likely to be ready for next week.
rrsagnet, set logs world-visible
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/MIME/MIME multipart/ Succeeded: s/fo/of/ Succeeded: s/WD/WD reflecting the new attribute./ Found Scribe: Norm Inferring ScribeNick: Norm Found ScribeNick: Norm Default Present: Ht, PGrosso, Norm, Vojtech, MoZ, Alex_Milows Present: Ht PGrosso Norm Vojtech MoZ Alex_Milows Agenda: http://www.w3.org/XML/XProc/2010/01/07-agenda Found Date: 07 Jan 2010 Guessing minutes URL: http://www.w3.org/2010/01/07-xproc-minutes.html People with action items: norm[End of scribe.perl diagnostic output]