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

XProc Minutes 26 Feb 2009

From: Norman Walsh <ndw@nwalsh.com>
Date: Wed, 11 Mar 2009 11:20:13 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <m2d4coqe6q.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2009/02/26-minutes

[1]W3C

                                   - DRAFT -

                            XML Processing Model WG

Meeting 137, 26 Feb 2009

   [2]Agenda

   See also: [3]IRC log

Attendees

   Present
           Norm, Paul, Vojtech, Alex, Mohamed, Henry

   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 5 Mar 2009?
         4. [8]Review of CR comments
         5. [9]089: conflicting content-type for body parts
         6. [10]090 p:hash and xml:base
         7. [11]091: duplication of information in c:multipart
         8. [12]092: p:http-request error content
         9. [13]093: p:http-request: status message
        10. [14]094: p:http-request content-type and encoding
        11. [15]Any other business?

     * [16]Summary of Action Items

   --------------------------------------------------------------------------

  Accept this agenda?

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

   Accepted.

  Accept minutes from the previous meeting?

   -> [18]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

   -> [19]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 [20]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
   [21]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
   [22]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 [23]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
   [24]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
   [25]http://www.w3.org/2009/02/26-xproc-minutes.html#action03]

   [End of minutes]

   --------------------------------------------------------------------------

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

References

   Visible links
   1. http://www.w3.org/
   2. http://www.w3.org/XML/XProc/2009/02/26-agenda
   3. http://www.w3.org/2009/02/26-xproc-irc
   4. file:///projects/w3c/WWW/XML/XProc/2009/02/26-minutes.html#agenda
   5. file:///projects/w3c/WWW/XML/XProc/2009/02/26-minutes.html#item01
   6. file:///projects/w3c/WWW/XML/XProc/2009/02/26-minutes.html#item02
   7. file:///projects/w3c/WWW/XML/XProc/2009/02/26-minutes.html#item03
   8. file:///projects/w3c/WWW/XML/XProc/2009/02/26-minutes.html#item04
   9. file:///projects/w3c/WWW/XML/XProc/2009/02/26-minutes.html#item05
  10. file:///projects/w3c/WWW/XML/XProc/2009/02/26-minutes.html#item06
  11. file:///projects/w3c/WWW/XML/XProc/2009/02/26-minutes.html#item07
  12. file:///projects/w3c/WWW/XML/XProc/2009/02/26-minutes.html#item08
  13. file:///projects/w3c/WWW/XML/XProc/2009/02/26-minutes.html#item09
  14. file:///projects/w3c/WWW/XML/XProc/2009/02/26-minutes.html#item10
  15. file:///projects/w3c/WWW/XML/XProc/2009/02/26-minutes.html#item11
  16. file:///projects/w3c/WWW/XML/XProc/2009/02/26-minutes.html#ActionSummary
  17. http://www.w3.org/XML/XProc/2009/02/26-agenda
  18. http://www.w3.org/XML/XProc/2009/02/05-minutes
  19. http://www.w3.org/XML/XProc/2008/11/cr-comments/
  20. http://www.w3.org/2009/02/26-xproc-minutes.html#action01
  21. http://www.w3.org/2009/02/26-xproc-minutes.html#action02
  22. http://www.w3.org/2009/02/26-xproc-minutes.html#action03
  23. http://www.w3.org/2009/02/26-xproc-minutes.html#action01
  24. http://www.w3.org/2009/02/26-xproc-minutes.html#action02
  25. http://www.w3.org/2009/02/26-xproc-minutes.html#action03
  26. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
  27. http://dev.w3.org/cvsweb/2002/scribe/

Received on Wednesday, 11 March 2009 15:21:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 11 March 2009 15:21:00 GMT