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

Re: p:http-request - duplication of information in c:multipart

From: Florent Georges <fgeorges@fgeorges.org>
Date: Tue, 3 Feb 2009 15:59:15 +0100
Message-ID: <ebaca5bf0902030659v5ba26180lb23b4e6d40268b43@mail.gmail.com>
To: Toman_Vojtech@emc.com
Cc: public-xml-processing-model-comments@w3.org

2009/2/3 ? wrote:

  Hi,

> <c:multipart boundary="-=-=-=-" content-type="multipart/mixed;
> boundary='-=-=-=-'">
> ...
> </c:multipart>

> Or should the result be:

> <c:multipart boundary="-=-=-=-" content-type="multipart/mixed">
> ...
> </c:multipart>

  That's an interesting question.  I've been facing the same
problem with an extension function for XSLT that I wrote a few
years ago.  IMHO I think it is convenient to provide the user
with common useful values in a strict format (for instance
@content-type is the content type string, and only this, without
extra param) on the one hand, and anyway, we provide the original
headers on the other hand (in c:header elements.)

  So I think that if the HTTP server does return the following
header:

    Content-Type: multipart/mixed; boundary='-=-=-=-'

then the response should look like the following:

    <c:response status="...">
       <c:header name="Content-Type"
                 value="multipart/mixed; boundary='-=-=-=-'"/>
       <c:header .../>
       <c:header .../>
       <c:multipart boundary="-=-=-=-"
                    content-type="multipart/mixed">
          ...
       </c:multipart>
    </c:response>

  For the headers, I think the actual draft is clear enough:
7.1.10.3 says "2. Each response header is translated into a
c:header element."  But I think that the way an attribute value
(as @content-type) is got from the original header is maybe
under-specified.

  Just my 2 cents...

  Regards,

-- 
Florent Georges
http://www.fgeorges.org/
Received on Tuesday, 3 February 2009 14:59:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 February 2009 14:59:55 GMT