Re: HTTP client module

John Snelson wrote:

> In general I really like this proposal. I've got a few comments
> or questions below:

  Thank you John for this valuable feedback.

  First of all, I realize this is maybe not clear enough: I rewrote
what I had initially (close to the implementation I made, available
at http://www.fgeorges.org/xslt/saxon-ext/) to be closer to the
step p:http-request in XProc (http://www.w3.org/TR/xproc/).  That
can help to understand some design choices.

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

  Actually, I got 16 signatures the day before posting it :-) I had
4 families of functions (always returning text, XML or binary, and
one that returned either one regarding the content-type) each in 4
different arities: from 1 to 4 params (only $request, $request and
$uri, etc.)

  I really want to be able to have a full, standalone request as
only one element (to not block user's imagination just because it
couldn't be added to a sequence then got back, etc.)  But when
sending big XML documents available as document nodes, I think this
is wasteful to copy it to the http:request element.

  Ok, that does not answer your question (that answers "why not
having just only one param?") :-)

  Yes, maybe we could have a signature with only one param, the
http:request element, and maybe also one with the target URI in
addition.

> 2) Shouldn't the $serial accept the name of a set of
> serialization parameters defined by xsl:output, as well as
> possibly an inline xsl:output element?

  Good catch!  I wanted to have the ability to pass the name of an
output definition, I just forget it while writing...

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

  I must admit I am not sure.  I always sent authorizations on
the first request in my original extension, while this option
exists in XProc to let the user decide if it is a good thing or
not.  I guess this is a security issue?  I can ask the XProc
community about a specific use case or an explanation of the
existence of this attribute...

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

  Well, for me that's an /XML media type./  Once again, this wording
(XML media types, textual media types) is taken from XProc.  I
thought it was quite intuitive.  XProc does not define those
expressions, but there is the RFC 3023, the abstract of which
begins by (http://www.ietf.org/rfc/rfc3023.txt):

    This document standardizes five new media types -- text/xml,
    application/xml, text/xml-external-parsed-entity,
    application/xml-external-parsed-entity, and application/xml-dtd
    -- for use in exchanging network entities that are related to
    the Extensible Markup Language (XML).  This document also
    standardizes a convention (using the suffix '+xml') for naming
    media types outside of these five types when those media types
    represent XML MIME (Multipurpose Internet Mail Extensions)
    entities.

> 5) What is the use case for status-only? Can't lazy evaluation
> achieve the same thing? Could you use a HEAD request instead?

  Well.  We are defining extensions, and I wouldn't trust an
extension to be able to lazy evaluate some of the items in the
sequence it returns.  For instance, if I am right, in Saxon that is
not possible with the current extension mechanism.

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

  See above.

> 7) Should HTML parsing (tidying) be optional? What about parsing
> other media types - could that also be implementation defined?

  Well...  First I think it is optional, as you can set attribute
override-content-type to "text/plain" to get the response body as a
string.  For other media types, I think one should just use the raw
text or binary body and parse it in XSLT or in an extension.

  Text and binary are clearly essential, as well as XML.  HTML is a
common use case I think, so it is very convenient to have it out of
the box.  For other types, I can't think of a spread use case, so I
would just left that aspect up to the user.  Unless one has a clear
use case there.

> 8) What is the use case for "override-content-type"?

  See above ;-)  When you know 1/ the server is sending a wrong
media type (very common I think) or 2/ you want to override the
default rules (you want the HTML document as a plain string, for
instance.)

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

  That's why the serialization of the content is let up to the XSLT
and XQuery Serialization recommendation :-)  If you pass an item of
type base64Binary, its lexical representation will be serialized.
So you get valid base64 in your body.

  I'll try to create a page on the wiki to summarize those points
and others as well as soon as I can.

  Thanks again for your comments,

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