Re: HTTP client module

"M. David Peterson" wrote:

> Florent: /GREAT/ to see you taking the initiative on this badly
> needed extension function!

  Thanks David!  I have some plans using it ;-)

> On Tue, Jan 20, 2009 at 6:25 AM, John Snelson
> <[email protected]>wrote:

> > 1) What about adding an alternative function signature with
> > only the $request parameter?

> +1: Providing a "call-back" function for processing the result
> would be helpful, /especially/ when passing state via
> parameters.

  I am not sure to understand what call-back functions are doing
here (well, I am sure I don't understand :-p.)

> > 2) Shouldn't the $serial accept the name of a set of
> > serialization parameters defined by xsl:output,

> It does, doesn't it? i.e.:

> >> If this is an XML media type, it is serialized using the
> >> parameter $serial.  This parameter can be an xsl:output
> >> element, as defined in [XSLT 2.0], and the serialization is
> >> defined in [XSLT and XQuery Serialization].  $serial can
> >> also be a string, either 'xml', 'html', 'xhtml' or
> >> 'text' (other values are implementation-defined, as
> >> explained in the above mentioned recommendations.)

> as well as possibly an inline xsl:output element?

> Inline?

  It seems this param is not clearly enough defined.  The intent
is to pass either 1/ a string (a serialization method, like
'text', using its default options) or 2/ a string (the name of an
output definition, that is, the name of a named xsl:output) or 3/
an xsl:output element itself:

    (: 1/ XPath :)
    http:send-request(..., 'text')

    <!-- 2/ XSLT -->
    <xsl:output name="indented" indent="yes"/>
    ...
       <xsl:sequence select="http:send-request(..., 'indented')"/>

    (: 2/ XQuery :)
    http:send-request(..., <xsl:output indent="yes"/>)

    <!-- 3/ XSLT -->
    <xsl:variable name="serial" as="element(xsl:output)">
       <xsl:output indent="yes"/>
    </xsl:variable>
    <xsl:sequence select="http:send-request(..., $serial)"/>

> > 3) What is the use case for send-authorization? Why not just
> > send authorization in the first request?

> I would assume for reasons of efficiency for sending
> non-authenticated requests?

  I don't think that computing the Authorization header is really
significant regarding the whole process of sending a request.  My
guess is that this has more to do with security.  That's why I
took it from XProc.  I will ask them to be sure.

> > 4) I think that the default serialization method needs to be
> > a bit more flexible - consider application/rdf+xml for
> > instance.

> Unless I'm missing something the default serialization method
> seems to be as flexible as it can be using named xsl:output
> elements combined with the default xml, html, xhtml, and text
> output serialization formats.

  I think that John's point is that the above media type should
be treated as an XML media type by default (without having to
explicitly provide a serializer.)  And that's the intent.  I
think the RFC 3023 which I pointed to in my previous email does
cover this case.  I should be more explicit thought, and add this
reference.

> > 5) What is the use case for status-only? Can't lazy
> > evaluation achieve the same thing?

> Not sure, but I can /definitely/ see several use cases in which
> the HTTP response code is all that's required in return to
> determine what to do next, allowing you to drop the response
> body for reasons of efficiency.

> > Could you use a HEAD request instead?

> Not if you PUT or POST content.  An example use case: POSTing
> content to a server in which the HTTP response status code is
> all that's required to determine if the POST was successful and
> what to do next.

  Yes, I agree with the above.

> > 6) "If the body media type is a textual type" - what does
> > that mean? What about text/xml?

> Isn't this a fairly well understood distinction in which a
> textual media type represents any non-(XML)structured
> string (i.e. escaped (X)HTML, base64, etc.), text/xml
> representing non application specific XML (AKA Plain Ol' XML),
> and application specific XML being specified as such using
> the "application/foo+xml" mime-type prefix/type-suffix format,
> all specified in the Content-Type request/response header?

  I agree with that, except than I think base64 should be
understood as binary.  The underlying request will encode it as
text (that's the purpose of base64) but the payload *is* the
binary stuff.  And again in this context, the RFC 3023.

  It seems I have to define more precisely what does xxx media
type mean (I'd like to not be too strict, to let a particular
implementation to do what it seems is good, but that also should
be more explicit.)

> > 7) Should HTML parsing (tidying) be optional?

> +1: Serializing an HTML string as-is in the output should be
> supported by default.

  I am not sure that was the point (I responded to the John's
question in my previous email.)  About your comment, I am not
sure to see exactly what you mean.  Is it to serialize an HTML
document as:

    &_lt;html&_gt;
       &_lt;head&_gt;
       ...

?

> > What about parsing other media types - could that also be
> > implementation defined?

> Isn't that handled already via:

> >> If the attribute override-content-type is set on the
> >> request, its value is used instead of the content-type
> >> returned by the HTTP server

  Yes and no.  It allows you to override the result content type
because you know the server is wrong or you want to treat the
payload another way, that does not allow an implementation to
treat a media type by default another way than defined.

  Maybe it would make things clearer to have an example use case?

> > 9) What about the ability to send base64Binary, or hexBinary?
> > I guess that would involve a binary serialization method.

> That's handled via MIME multipart:
> http://en.wikipedia.org/wiki/Multipart_message#Multipart_messages

  Not really.  Multi-part allows you to send different entities
in one single message.  One of the usage is to have alternative
representations (for instance HTML and plain text for an email.)
But you can also have one single message, with one single entity
which is binary (an image for instance.)  In the message, this is
represented as base64.  And if you have binary in XSLT, then you
have it as base64Binary or hexBinary.  So if you set the content
type accordingly, the serialization recommendation should do the
job.

  Thanks for your comments!

  Regards,

-- 
Florent Georges
http://www.fgeorges.org/