- From: Norman Walsh <ndw@nwalsh.com>
- Date: Wed, 20 Jan 2010 08:29:56 -0500
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <m2hbqggazv.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2010/01/07-minutes
[1]W3C
- DRAFT -
XML Processing Model WG
Meeting 163, 07 Jan 2010
[2]Agenda
See also: [3]IRC log
Attendees
Present
Henry, Paul, Norm, Vojtech, Mohamed, Alex
Regrets
Chair
Norm
Scribe
Norm
Contents
* [4]Topics
1. [5]Accept this agenda?
2. [6]Accept minutes from the previous meeting?
3. [7]Next meeting: telcon, 14 Jan 2010?
4. [8]New Last Call WD published
5. [9]Creating MIME multipart documents with p:http-request
6. [10]Comments on the latest draft?
7. [11]Test suite progress?
8. [12]Default processing model progress?
9. [13]Any other business?
* [14]Summary of Action Items
--------------------------------------------------------------------------
Accept this agenda?
Happy New Year to all!
-> [15]http://www.w3.org/XML/XProc/2010/01/07-agenda
Accepted.
Accept minutes from the previous meeting?
-> [16]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
-> [17]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.
->
[18]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 [19]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 [20]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.
Summary of Action Items
[NEW] ACTION: Norm to produce a new WD reflecting the new attribute.
[recorded in [21]http://www.w3.org/2010/01/07-xproc-minutes.html#action01]
[End of minutes]
--------------------------------------------------------------------------
Minutes formatted by David Booth's [22]scribe.perl version 1.135 ([23]CVS
log)
$Date: 2010/01/20 13:24:06 $
References
1. http://www.w3.org/
2. http://www.w3.org/XML/XProc/2010/01/07-agenda
3. http://www.w3.org/2010/01/07-xproc-irc
4. http://www.w3.org/XML/XProc/2010/01/07-minutes#agenda
5. http://www.w3.org/XML/XProc/2010/01/07-minutes#item01
6. http://www.w3.org/XML/XProc/2010/01/07-minutes#item02
7. http://www.w3.org/XML/XProc/2010/01/07-minutes#item03
8. http://www.w3.org/XML/XProc/2010/01/07-minutes#item04
9. http://www.w3.org/XML/XProc/2010/01/07-minutes#item05
10. http://www.w3.org/XML/XProc/2010/01/07-minutes#item06
11. http://www.w3.org/XML/XProc/2010/01/07-minutes#item07
12. http://www.w3.org/XML/XProc/2010/01/07-minutes#item08
13. http://www.w3.org/XML/XProc/2010/01/07-minutes#item09
14. http://www.w3.org/XML/XProc/2010/01/07-minutes#ActionSummary
15. http://www.w3.org/XML/XProc/2010/01/07-agenda
16. http://www.w3.org/XML/XProc/2009/12/17-minutes
17. http://www.w3.org/TR/xproc/
18. http://www.w3.org/mid/28d56ece0912171510k4ce5e358g5a155bd7b0957a35@mail.gmail.com
19. http://tools.ietf.org/html/rfc2387
20. http://www.w3.org/2010/01/07-xproc-minutes.html#action01
21. http://www.w3.org/2010/01/07-xproc-minutes.html#action01
22. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
23. http://dev.w3.org/cvsweb/2002/scribe/
Received on Wednesday, 20 January 2010 13:30:31 UTC