W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > January 2010

XProc Minutes 7 Jan 2010

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


                                   - DRAFT -

                            XML Processing Model WG

Meeting 163, 07 Jan 2010


   See also: [3]IRC log


           Henry, Paul, Norm, Vojtech, Mohamed, Alex





     * [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


  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

   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

   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

   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
   ... 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

   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.


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
    $Date: 2010/01/20 13:24:06 $


   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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:48 UTC