Re: XProc Minutes 5 June 2008

On Thu, Jun 5, 2008 at 8:44 AM, Norman Walsh <ndw@nwalsh.com> wrote:

>   Vojtech: In Section 7.1.9.3 there's an attribute @detailed which if it's
>   set to false, it's not clear what the step should generate.
>   ... I think that if detailed=false, the c:response is not generated.
>
>   <scribe> ACTION: Alex to investigate [recorded in
>   http://www.w3.org/2008/06/05-xproc-minutes.html#action04[10]]

In section 7.1.9.3 it says:

The value of the detailed attribute determines the content of the
result document. If it is "true", the response to the request is
handled as follows:

   1.

      A single c:response element is produced with the status
attribute containing the status of the response received.
   2.

      Each response header is translated into a c:header element.
   3.

      Unless the status-only attribute has a value "true", the entity
body of the response is converted into a c:body or c:multipart element
via the rules given in the next section.

Otherwise (the detailed attribute is not specified or its value is
"false"), the response to the request is handled as follows:

   1.

      If the media type (as determined by the override-content-type
attribute or the Content-Type response header) is an XML media type,
the entity is decoded if necessary, then parsed as an XML document and
produced on the result output port as the entire output of the step.
   2.

      Otherwise, the entity body of the response is converted into a
c:body or c:multipart element via the rules given in the next section.


>
>   Vojtech: And then there's the question of what to do if the response is a
>   multipart response where there are nested multiparts.
>
>   Norm: It's not immediately clear that that makes sense for us, but we
>   should investigate.
>
>   <scribe> ACTION: Alex to investigate [recorded in
>   http://www.w3.org/2008/06/05-xproc-minutes.html#action05[11]]


While it is possible to have parts in a multi-part message that are themselves
an encoded multipart message, you would have troubles guaranteeing that
the part that is mutlipart could always be embedded (whew!).  As such, you'd
probably want to base64 encode that part.  If you didn't, in our model  you
would only get one level of multipart decoding.  That is, you'd get the mime
encoded message as one of the bodies with the media type set to
"multipart/mixed"
or something like that.


>
>   Vojtech: Two more things.
>   ... In Section 7.1.9.2 there are two conditions: if the content-type is
>   XML or the encoding is base64 or not.
>   ... Then different things can happen, but it seems to me that if the
>   content-type is XML and encoding is base64 then the result is unspecified.
>
>   Norm: I think the right thing is decode it and parse it, but we should say
>   that.
>
>   <scribe> ACTION: Alex to fix. [recorded in
>   http://www.w3.org/2008/06/05-xproc-minutes.html#action06[12]]

Actually, no.  This is the request.  If the code is base64 encoded already then,
magically, some step produced the right byte-sequence encoding of an
XML document.  As such, that we set the appropriate headers and dump
the base64 encoded content into the request entity body.

>
>   Vojtech: The last one is more of a question, in 7.1.9.4 there's a note
>   about text/html
>   ... that says it'll be base64 encoded. But earlier it says that text types
>   aren't encoded that way.
>   ... So I wonder what the right answer is.
>
>   Norm: Yeah, that does seem strange. I'd have expected the text to just be
>   escaped markup.

Hmm... I don't remember writing that note so I won't claim to understand
it.

I think we just strike it.  We don't need to explain text/html because I
think it is clear from the passage that:

   * if you receive text/html with a unicode charset parameter, you
can translate
      the entity body into a sequence of unicode characters and escape the
     appropriate characters.

   * if you receive text/html without a unicode charset parameter, you
get a base64
     encoded blob.

-- 
--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics

Received on Thursday, 12 June 2008 15:11:30 UTC