Re: HTTP client module
"M. David Peterson" <[email protected]> Tue, 20 Jan 2009 07:34:28 -0700
| Newsgroups | gmane.text.xml.xslt.extensions |
|---|---|
| Message-ID | <[email protected]> |
--===============0986281379== Content-Type: multipart/alternative; boundary="----=_Part_41748_2673673.1232462068675" ------=_Part_41748_2673673.1232462068675 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hey John, Interesting comments. My follow-up to your comments follow inline below. Florent: /GREAT/ to see you taking the initiative on this badly needed extension function! On Tue, Jan 20, 2009 at 6:25 AM, John Snelson <[email protected]>wrote: > Hi Florent, > > In general I really like this proposal. I've got a few comments or > questions below: > > 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. > 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]<http://www.fgeorges.org/xslt/exslt2/http-client.html#xslt20>, >> and the serialization is defined in [XSLT and XQuery Serialization]<http://www.fgeorges.org/xslt/exslt2/http-client.html#xserial>. >> $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? > 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? > 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. > 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. > 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? > 7) Should HTML parsing (tidying) be optional? +1: Serializing an HTML string as-is in the output should be supported by default. 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 > > ? > 8) What is the use case for "override-content-type"? See above? 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 -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: [email protected] | [email protected] Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://www.oreillynet.com/pub/au/2354 | http://broadcast.oreilly.com/m-david-peterson/ ------=_Part_41748_2673673.1232462068675 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hey John,<br><br>Interesting comments. My follow-up to your comments follow inline below.<br><br>Florent: /GREAT/ to see you taking the initiative on this badly needed extension function!<br><br><div class="gmail_quote">On Tue, Jan 20, 2009 at 6:25 AM, John Snelson <span dir="ltr"><<a href="mailto:[email protected]">[email protected]</a>></span> wrote:<br> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi Florent,<br> <br> In general I really like this proposal. I've got a few comments or questions below:<br> <br> 1) What about adding an alternative function signature with only the $request parameter?</blockquote><div><br>+1: Providing a "call-back" function for processing the result would be helpful, /especially/ when passing state via parameters.<br> </div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 2) Shouldn't the $serial accept the name of a set of serialization parameters defined by xsl:output, </blockquote><div><br>It does, doesn't it? i.e.:<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote"> <blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote"><a name="d2e289" id="d2e289"> If this is an XML media type, it is serialized using the parameter <code>$serial</code>. This parameter can be an <code>xsl:output</code> element, as defined in </a><a href="http://www.fgeorges.org/xslt/exslt2/http-client.html#xslt20">[XSLT 2.0]</a>, and the serialization is defined in <a href="http://www.fgeorges.org/xslt/exslt2/http-client.html#xserial">[XSLT and XQuery Serialization]</a>. <code>$serial</code> can also be a string, either '<code>xml</code>', '<code>html</code>', '<code>xhtml</code>' or '<code>text</code>' (other values are implementation-defined, as explained in the above mentioned recommendations.)<br></blockquote></blockquote><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> as well as possibly an inline xsl:output element?</blockquote><div><br>Inline?<br></div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 3) What is the use case for send-authorization? Why not just send authorization in the first request?</blockquote><div><br>I would assume for reasons of efficiency for sending non-authenticated requests?<br></div><div> </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 4) I think that the default serialization method needs to be a bit more flexible - consider application/rdf+xml for instance.</blockquote><div><br>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.<br> </div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 5) What is the use case for status-only? Can't lazy evaluation achieve the same thing? </blockquote><div><br>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.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Could you use a HEAD request instead?</blockquote><div><br>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.<br> </div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 6) "If the body media type is a textual type" - what does that mean? What about text/xml?</blockquote><div><br>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?<br> </div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 7) Should HTML parsing (tidying) be optional?</blockquote><div><br>+1: Serializing an HTML string as-is in the output should be supported by default. <br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> What about parsing other media types - could that also be implementation defined?</blockquote><div><br>Isn't that handled already via:<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote"> <blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote"><a name="d2e437" id="d2e437">If the attribute <code>override-content-type</code> is set on the request, its value is used instead of the content-type returned by the HTTP server</a></blockquote></blockquote><div><br>? <br></div><div> <br></div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 8) What is the use case for "override-content-type"?</blockquote><div><br>See above? <br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 9) What about the ability to send base64Binary, or hexBinary? I guess that would involve a binary serialization method.</blockquote><div><br>That's handled via MIME multipart: <a href="http://en.wikipedia.org/wiki/Multipart_message#Multipart_messages">http://en.wikipedia.org/wiki/Multipart_message#Multipart_messages</a></div> </div><br>-- <br>/M:D<br><br>M. David Peterson<br>Co-Founder & Chief Architect, 3rd&Urban, LLC<br>Email: [email protected] | <a href="mailto:[email protected]">[email protected]</a><br>Mobile: (206) 999-0588<br><a href="http://3rdandUrban.com">http://3rdandUrban.com</a> | <a href="http://amp.fm">http://amp.fm</a> | <a href="http://www.oreillynet.com/pub/au/2354">http://www.oreillynet.com/pub/au/2354</a> | <a href="http://broadcast.oreilly.com/m-david-peterson/">http://broadcast.oreilly.com/m-david-peterson/</a><br> ------=_Part_41748_2673673.1232462068675-- --===============0986281379== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ exslt mailing list [email protected] http://www.exslt.org/list --===============0986281379==--