Re: HTTP client module
"M. David Peterson" <[email protected]> Wed, 21 Jan 2009 02:50:19 -0700
| Newsgroups | gmane.text.xml.xslt.extensions |
|---|---|
| Message-ID | <[email protected]> |
--===============0757291257== Content-Type: multipart/alternative; boundary=000e0cd2c14a70f1340460fb15d9 --000e0cd2c14a70f1340460fb15d9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Tue, Jan 20, 2009 at 8:02 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. >> > So I'm not sure why I read that the first time and thought "alternative function signature" was in reference to a signature of an extension method with an "alternative 'function'" passed as a parameter, but for whatever reason, I did. *YIKES*! :-) > >> > Callback functions aren't really an option without adopting some kind of > first class functions. I'm not convinced of the merits of callback in this > case. Especially when you consider the above muff! ;-) 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.: >> > > I think the proposal is unclear here. To me, it says that you can either > pass the 4 strings ("xml", "html", etc.), or you can pass an xsl:output > element, ie: > > http:send-request($uri, $content, $request, > <xsl:output method="xml" omit-xml-declaration="yes"/>) Which would be illegal in XSLT. Have you been smoking too much XQuery John? Haha! I kid! ;-) Of course I believe this is also the source of the confusion: I read "This parameter can be an |xsl:output|element" and think of the string value of xsl:output/@name as what it refers to whereas I can easily see and understand why thinking if XQuery terms you would read it as the XML literal <xsl:output ... /> embedded inline. Of course embedded XML literals support in XQuery invokes one of those "you know, I /really/ do like that feature" moments that makes me envious from time to time of XQuery syntax. But then I remind myself of the lack of an xsl:template equivalent and get over it fairly quickly. Usually. ;-) I've seen people propose adding the above way of giving serialization > options, since they can then be decided dynamically. I think that's > interesting, but not essential. I think the ability to reference a named > xsl:output element /is/ essential though. As per above we are most definitely in agreement. There's no other way for it to work. :-) 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 would imagine that if the user requests authentication, it would be more > efficient to send the authorization credentials in the first request. True, though I believe somewhere within: The attribute auth-method can be either "Basic" or "Digest", but other > values can also be used, in an implementation-defined way. The handling of > those attributes must be done in conformance to [RFC 2617]<http://www.fgeorges.org/xslt/exslt2/http-client.html#rfc2617>. > If send-authorization is true (default value is false) and the > authentication method supports generating the header Authorization without > challenge, the request contains this header. The default value is to send a > non-authenticated request, and if the response is an authentication > challenge, then only send the credentials in a second message. ... exists the reasoning and justification for implementing the * send-authorization* boolean i.e. setting the *Authorization *header and sending the credentials without first checking for an authentication challenge in the response to then set the header and send the credentials in a follow-up request. I can see the benefit of invoking a non-authenticated request and falling back to sending the credentials in a follow-up response if the initial request returns an authentication challenge as this ensures I'm only setting the header and sending the credentials when it's absolutely mandatory. At the same time I can see why setting the *send-authorization*boolean to true would allow you to speed things up when you're absolutely certain authorization credentials are required by allowing you to override the fallback-to-auth behavior if/when it seems justified in doing so. 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. > Section 3.2 says that the default serialization mode is based on the > content-type of the message body: > > "'xml', 'html' and 'xhtml' are the default for corresponding media types, > and 'text' for other media types" > > Now xml has two well known media types ("text/xml" and "application/xml"), > but there are a number of media types that use XML but might not be > considered "xml" media types ("application/rdf+xml", for instance). > > Whatever is intended, this needs firming up in the proposal. I guess I've never viewed application/anything+xml as anything other than an XML media type. e.g. application/rdf+xml is an XML media type because of its XML serialization foundation. Maybe we're looking at what defines XML and what defines an XML media type through different colored glasses? 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. >> > In that case, lazy evaluation should be sufficient for efficiency. Results > that aren't needed won't be evaluated. Can you describe how you're defining lazy evaluation in this case? Take for example AtomPub: The response of an AtomPub POST operation is the resulting atom:entry containing various element and attribute values that are determined by the server once the POST operation has completed successfully. There may be cases in which parsing the atom:entry-based XML response will provide meaningful data that is used in continuing an operation on the requesting client. However, often times that data isn't anything that can't be obtained at a later date through an introspection GET request or a basic query mechanism of some sort. So hanging on to the atom:entry response envelope and returning it to the extension method for further processing is an unneccessary use of system resources, something that could be avoided completely by setting the status-only boolean paramater to true. Using the above example, how would you propose using lazy evaluation to avoid consuming the resources required to parse the response and return it to the calling extension method in cases where that data provides no meaningful benefit to the current task at hand? 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? >> > Can you point to a specification where a "textual media type" is defined? Not off hand, no. > If not, then this specification needs to define it. I see your point. My thoughts were that the most obvious definition would be a media type that > started with "text" - but then what about "text/xml". Well XML is text, so technically speaking text/xml is a valid way of specifying a glob of non-application** specific XML -- often referred to as POX, or Plain Ol' XML -- as content that should be parsed by a non-domain specific XML parser with schema validation turned off. The same both can and should be said about text/css, or text/javascript, or etc. in which there is no domain specific use for streams textual content and therefore should be parsed by the vanilla flavored CSS, Javascript, etc. parser(s) and rendered accordingly. ** I really wish they would have chosen the term "domain" rather than "application" to describe mime-types with a specific defined purpose, but to each his own ;-) 7) Should HTML parsing (tidying) be optional? > > > +1: Serializing an HTML string as-is in the output should be supported by > default. > I think you misunderstand - I'm wondering if it should be changed to be > optional. I don't think I'm misunderstanding. I agree: Setting it as optional ensures the ability to treat an escaped HTML string as something that should either be serialized to HTML as-is w/o first tidying it or rendered in its escaped form. e.g. Creating an HTML tutorial in which a bad example and good example are provided for comparison. My thoughts are that that HTML parsing into an XML infoset is a subjective > process, and libraries to do such things might not always be available. Absolutely agree. > I do think it's very useful functionality, though. Agreed. It would be absolutely /fantastic/ to find an effort being made to create an agreed upon tidy mapping of HTML to XHTML in which the various HTML tidy libraries of the world could conform to. Anyone know of any efforts in this space? 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 >> ? >> > > No. I want the ability to return an XML representation of JSON if the mime > type is "application/json", for instance. Ahh, okay. That makes sense, though wouldn't that be better handled as part of transformation logic, transforming the response into the desired serialization as part of a sub-process rather than specifying the desired serialization passed in via a parameter? Or am I completely missing the boat on this one? My understanding is that "override-content-type" will only allow me to tell > the implementation to treat (for instance) a response with mime type > "image/jpeg" as "application/xml" and try to parse it. That sounds dangerous > to me, so I'd like a good use case for having the functionality. Oh, it's /definitely/ dangerous, but not sure it's a problem that can be easily solved w/o sacrificing the use cases in which overriding the mime-type can produced desirable side effects e.g. treating RDF thats served up as text/xml as application/rdf+xml, automatically invoking the registered system process for handling the application/rdf+xml mime type as a result, returning, for example, RDF triples to the parent process for further querying/transformation/serialization. > 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 >> > What I mean is, if I have an item of type xs:base64Binary, how can I send > that as a binary payload in an HTTP request. As part of the /http:request/http:multipart/http:header|http:body elements. > Even if multipart-mime supports that, the http:send-request() function also > needs to support that. Unless I'm missing something more obvious, it does via the required *$request as element(http:request)?* parameter. So a completely non-related question, but while I have your ear: Do you know if memcachedb[1] could use Berkeley DB XML interchangeably with Berkeley DB as its persistent data store, gaining the XML-ified benefits of using Berkeley DB XML over Berkeley DB as an unintended side effect of using memcachedb for maintaining data persistence of memcached data? While storing key/value pairs in Berkeley DB doesn't allow for querying the contained data on anything other than the seemingly unstructured keyed values, if those same values being stored were being viewed by Berkeley DB XML as insert operations of well formed XML, as long as the values /were/ well formed XML, the end result would be that of gaining the distributed caching benefits of memcached with the structured data persistence (and therefore (X)Queryable) benefits of Berkeley DB XML. Obviously something that would need to moved to a completely separate thread, but if you happen to know if this is concievably possible, or if it would be a complete waste of time and effort and should therefore be avoided, and wouldn't mind sharing that information with me I would be extremely grateful. :-) Thanks in advance! :-) [1] http://memcachedb.org/ -- /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/ --000e0cd2c14a70f1340460fb15d9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Jan 20, 2009 at 8:02 AM, John Snelson <span dir=3D"ltr"><<a href= =3D"mailto:[email protected]">[email protected]</a>></span> = wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl= e=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; = padding-left: 1ex;"> <br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(2= 04, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class=3D= "Ih2E3d"> 1) What about adding an alternative function signature with o= nly the<br> $request parameter?<br> <br> <br> +1: Providing a "call-back" function for processing the result wo= uld be helpful, /especially/ when passing state via parameters.</div></bloc= kquote></blockquote><div><br>So I'm not sure why I read that the first = time and thought "alternative function signature" was in referenc= e to a signature of an extension method with an "alternative 'func= tion'" passed as a parameter, but for whatever reason, I did.<br> <br>*YIKES*! :-)<br></div><blockquote class=3D"gmail_quote" style=3D"border= -left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-lef= t: 1ex;"><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid = rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class=3D"Ih2E3d"><br> </div></blockquote> <br> Callback functions aren't really an option without adopting some kind o= f first class functions. I'm not convinced of the merits of callback in= this case.</blockquote><div><br>Especially when you consider the above muf= f! ;-) <br> <br> </div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb= (204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><blockquote= class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 204, 204); = margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class=3D"Ih2E3d"> 2) Shouldn't the $serial accept the name of a set of seri= alization<br> parameters defined by xsl:output, <br> <br> It does, doesn't it? i.e.:<br></div></blockquote><br> I think the proposal is unclear here. To me, it says that you can either pa= ss the 4 strings ("xml", "html", etc.), or you can pass= an xsl:output element, ie:<br> <br> http:send-request($uri, $content, $request,<br> <xsl:output method=3D"xml" omit-xml-declaration=3D"= ;yes"/>)</blockquote><div><br>Which would be illegal in XSLT. = Have you been smoking too much XQuery John?<br><br>Haha! I kid! ;-) = Of course I believe this is also the source of the confusion: I read "= This parameter can be an |xsl:output|element" and think of the string = value of xsl:output/@name as what it refers to whereas I can easily see and= understand why thinking if XQuery terms you would read it as the XML liter= al <xsl:output ... /> embedded inline.<br> <br>Of course embedded XML literals support in XQuery invokes one of those = "you know, I /really/ do like that feature" moments that makes me= envious from time to time of XQuery syntax.<br><br>But then I remind mysel= f of the lack of an xsl:template equivalent and get over it fairly quickly.= Usually. ;-)<br> <br></div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid= rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> I've seen people propose adding the above way of giving serialization o= ptions, since they can then be decided dynamically. I think that's inte= resting, but not essential. I think the ability to reference a named xsl:ou= tput element /is/ essential though.</blockquote> <div class=3D"Ih2E3d"><br>As per above we are most definitely in agreement.= There's no other way for it to work. :-)<br><br><br><br> <blockquote style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt= 0pt 0pt 0.8ex; padding-left: 1ex;" class=3D"gmail_quote"><blockquote class= =3D"gmail_quote" style=3D"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<br> authorization in the first request?<br> <br> I would assume for reasons of efficiency for sending non-authenticated requ= ests?<br> </blockquote></blockquote> <br></div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid= rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> I would imagine that if the user requests authentication, it would be more = efficient to send the authorization credentials in the first request.</bloc= kquote><div class=3D"Ih2E3d"><br>True, though I believe somewhere within:<b= r> <br><blockquote style=3D"border-left: 1px solid rgb(204, 204, 204); margin:= 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class=3D"gmail_quote"><a name=3D"d2= e354" id=3D"d2e354">The attribute <code>auth-method</code> can be either &q= uot;<code>Basic</code>" or "<code>Digest</code>", but other values can also b= e used, in an implementation-defined way. The handling of those attribute= s must be done in conformance to </a><a href=3D"http://www.fgeorges.org/xsl= t/exslt2/http-client.html#rfc2617">[RFC 2617]</a>. If <code>send-authoriza= tion</code> is true (default value is false) and the authentication meth= od supports generating the header <code>Authorization</code> without cha= llenge, the request contains this header. The default value is to send = a non-authenticated request, and if the response is an authentication challenge,= then only send the credentials in a second message. </blockquote><div><br>... exists the reasoning and justificatio= n for implementing the <i>send-authorization</i> boolean i.e. setting the <= i>Authorization </i>header and sending the credentials without first checki= ng for an authentication challenge in the response to then set the header a= nd send the credentials in a follow-up request. I can see the benefit of in= voking a non-authenticated request and falling back to sending the credenti= als in a follow-up response if the initial request returns an authenticatio= n challenge as this ensures I'm only setting the header and sending the= credentials when it's absolutely mandatory. At the same time I c= an see why setting the <i>send-authorization</i> boolean to true would allo= w you to speed things up when you're absolutely certain authorization c= redentials are required by allowing you to override the fallback-to-auth be= havior if/when it seems justified in doing so.<br> </div><br> <blockquote class=3D"gmail_quote" style=3D"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<br> more flexible - consider application/rdf+xml for instance.<br= > <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 t= he default xml, html, xhtml, and text output serialization formats.<br> </blockquote> <br></div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid= rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Section 3.2 says that the default serialization mode is based on the conten= t-type of the message body:<br> <br> "'xml', 'html' and 'xhtml' are the default for= corresponding media types, and 'text' for other media types"<= br> <br> Now xml has two well known media types ("text/xml" and "appl= ication/xml"), but there are a number of media types that use XML but = might not be considered "xml" media types ("application/rdf+= xml", for instance).<br> <br> Whatever is intended, this needs firming up in the proposal.</blockquote><d= iv class=3D"Ih2E3d"><br>I guess I've never viewed application/anything+= xml as anything other than an XML media type. e.g. application/rdf+xm= l is an XML media type because of its XML serialization foundation. Maybe w= e're looking at what defines XML and what defines an XML media type thr= ough different colored glasses? <br> <br> <blockquote style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt= 0pt 0pt 0.8ex; padding-left: 1ex;" class=3D"gmail_quote"><blockquote class= =3D"gmail_quote" style=3D"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 evalu= ation<br> achieve the same thing? <br> <br> Not sure, but I can /definitely/ see several use cases in which the HTTP re= sponse code is all that's required in return to determine what to do ne= xt, allowing you to drop the response body for reasons of efficiency.<br> </blockquote></blockquote> <br></div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid= rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> In that case, lazy evaluation should be sufficient for efficiency. Results = that aren't needed won't be evaluated.</blockquote><div class=3D"Ih= 2E3d"><br>Can you describe how you're defining lazy evaluation in this = case? Take for example AtomPub: The response of an AtomPub POST opera= tion is the resulting atom:entry containing various element and attribute v= alues that are determined by the server once the POST operation has complet= ed successfully. There may be cases in which parsing the atom:entry-b= ased XML response will provide meaningful data that is used in continuing a= n operation on the requesting client. However, often times that data = isn't anything that can't be obtained at a later date through an in= trospection GET request or a basic query mechanism of some sort. So hanging= on to the atom:entry response envelope and returning it to the extension m= ethod for further processing is an unneccessary use of system resources, so= mething that could be avoided completely by setting the status-only boolean= paramater to true.<br> <br>Using the above example, how would you propose using lazy evaluation to= avoid consuming the resources required to parse the response and return it= to the calling extension method in cases where that data provides no meani= ngful benefit to the current task at hand?<br> <br> <blockquote style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt= 0pt 0pt 0.8ex; padding-left: 1ex;" class=3D"gmail_quote"><blockquote class= =3D"gmail_quote" style=3D"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" - wha= t does that mean?<br> What about text/xml?<br> <br> Isn't this a fairly well understood distinction in which a textual medi= a type represents any non-(XML)structured string (i.e. escaped (X)HTML, bas= e64, etc.), text/xml representing non application specific XML (AKA Plain O= l' XML), and application specific XML being specified as such using the= "application/foo+xml" mime-type prefix/type-suffix format, all s= pecified in the Content-Type request/response header?<br> </blockquote></blockquote> <br></div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid= rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Can you point to a specification where a "textual media type" is = defined?</blockquote><div><br>Not off hand, no.<br> <br></div><blockqu= ote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 204, 204= ); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> If not, then this specification needs to define it. </blockquote><div><br>= I see your point. <br><br></div><blockquote class=3D"gmail_quote" style=3D"= border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; paddi= ng-left: 1ex;"> My thoughts were that the most obvious definition would be a media type tha= t started with "text" - but then what about "text/xml".= </blockquote><div class=3D"Ih2E3d"><br>Well XML is text, so technically spe= aking text/xml is a valid way of specifying a glob of non-application** spe= cific XML -- often referred to as POX, or Plain Ol' XML -- as content t= hat should be parsed by a non-domain specific XML parser with schema valida= tion turned off. The same both can and should be said about text/css, or te= xt/javascript, or etc. in which there is no domain specific use for streams= textual content and therefore should be parsed by the vanilla flavored CSS= , Javascript, etc. parser(s) and rendered accordingly.<br> <br>** I really wish they would have chosen the term "domain" rat= her than "application" to describe mime-types with a specific defined purp= ose, but to each his own ;-)<br><br> <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 7) Should HTML parsing (tidying) be optional?<br> <br> <br> +1: Serializing an HTML string as-is in the output should be supported by d= efault.<br> </blockquote> <br></div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid= rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> I think you misunderstand - I'm wondering if it should be changed to be= optional.</blockquote><div><br>I don't think I'm misunderstanding.= I agree: Setting it as optional ensures the ability to treat an escaped HT= ML string as something that should either be serialized to HTML as-is w/o f= irst tidying it or rendered in its escaped form. e.g. Creating an HTM= L tutorial in which a bad example and good example are provided for compari= son.<br> <br></div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid= rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> My tho= ughts are that that HTML parsing into an XML infoset is a subjective proces= s, and libraries to do such things might not always be available.</blockquo= te> <div><br>Absolutely agree.<br> <br></div><blockquote class=3D"gmail_qu= ote" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0p= t 0.8ex; padding-left: 1ex;"> I do think it's very useful functionality= , though.</blockquote> <div class=3D"Ih2E3d"><br>Agreed. It would be absolutely /fantastic/ = to find an effort being made to create an agreed upon tidy mapping of HTML = to XHTML in which the various HTML tidy libraries of the world could confor= m to. Anyone know of any efforts in this space?<br> <br><br> <blockquote style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt= 0pt 0pt 0.8ex; padding-left: 1ex;" class=3D"gmail_quote"><blockquote class= =3D"gmail_quote" style=3D"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<br> implementation defined?</blockquote></blockquote></div><block= quote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 204, 2= 04); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"></blockquote><div> = ;</div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rg= b(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class=3D"Ih2E3d"><blockquote style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class=3D"gmail_qu= ote"> Isn't that handled already via:<br><br> If the attribute |override-content-type| is set= on the request,<br> its value is used instead of the content-type r= eturned by the<br> HTTP server<br> ?<br></blockquote> <br></div> No. I want the ability to return an XML representation of JSON if the mime = type is "application/json", for instance.</blockquote><div><br>Ah= h, okay. That makes sense, though wouldn't that be better handled as pa= rt of transformation logic, transforming the response into the desired seri= alization as part of a sub-process rather than specifying the desired seria= lization passed in via a parameter? Or am I completely missing the boat on = this one?<br> <br></div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid= rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> My understanding is that "override-content-type" will only allow = me to tell the implementation to treat (for instance) a response with mime = type "image/jpeg" as "application/xml" and try to parse= it. That sounds dangerous to me, so I'd like a good use case for havin= g the functionality.</blockquote> <div class=3D"Ih2E3d"><br>Oh, it's /definitely/ dangerous, but not sure= it's a problem that can be easily solved w/o sacrificing the use cases= in which overriding the mime-type can produced desirable side effects e.g.= treating RDF thats served up as text/xml as application/rdf+xml, automatic= ally invoking the registered system process for handling the application/rd= f+xml mime type as a result, returning, for example, RDF triples to the par= ent process for further querying/transformation/serialization. <br> <br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(2= 04, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <br><blockquote style=3D"border-left: 1px solid rgb(204, 204, 204); margin:= 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class=3D"gmail_quote"> 9) What about the ability to send base64Binary, or hexBinary?= I<br> guess that would involve a binary serialization method.<br><b= r> That's handled via MIME multipart: <a href=3D"http://en.wikipedia.org/w= iki/Multipart_message#Multipart_messages" target=3D"_blank">http://en.wikip= edia.org/wiki/Multipart_message#Multipart_messages</a><br></blockquote> </blockquote> <br></div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid= rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> What I mean is, if I have an item of type xs:base64Binary, how can I send t= hat as a binary payload in an HTTP request. </blockquote><div><br>As part o= f the /http:request/http:multipart/http:header|http:body elements.<br> <br></div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px= solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">E= ven if multipart-mime supports that, the http:send-request() function also = needs to support that.</blockquote> <div><br>Unless I'm missing something more obvious, it does via the req= uired <i>$request as element(http:request)?</i> parameter.</div></div><br>S= o a completely non-related question, but while I have your ear: Do you know= if memcachedb[1] could use Berkeley DB XML interchangeably with Berkeley D= B as its persistent data store, gaining the XML-ified benefits of using Ber= keley DB XML over Berkeley DB as an unintended side effect of using memcach= edb for maintaining data persistence of memcached data? While storing= key/value pairs in Berkeley DB doesn't allow for querying the containe= d data on anything other than the seemingly unstructured keyed values, if t= hose same values being stored were being viewed by Berkeley DB XML as inser= t operations of well formed XML, as long as the values /were/ well formed X= ML, the end result would be that of gaining the distributed caching benefit= s of memcached with the structured data persistence (and therefore (X)Query= able) benefits of Berkeley DB XML.<br> <br>Obviously something that would need to moved to a completely separate t= hread, but if you happen to know if this is concievably possible, or if it = would be a complete waste of time and effort and should therefore be avoide= d, and wouldn't mind sharing that information with me I would be extrem= ely grateful. :-)<br> <br>Thanks in advance! :-)<br><br>[1] <a href=3D"http://memcachedb.org/">ht= tp://memcachedb.org/</a><br><br>-- <br>/M:D<br><br>M. David Peterson<br>Co-= Founder & Chief Architect, 3rd&Urban, LLC<br>Email: m.david@3rdandU= rban.com | <a href=3D"mailto:[email protected]">[email protected]</a><br> Mobile: (206) 999-0588<br><a href=3D"http://3rdandUrban.com">http://3rdandU= rban.com</a> | <a href=3D"http://amp.fm">http://amp.fm</a> | <a href=3D"htt= p://www.oreillynet.com/pub/au/2354">http://www.oreillynet.com/pub/au/2354</= a> | <a href=3D"http://broadcast.oreilly.com/m-david-peterson/">http://broa= dcast.oreilly.com/m-david-peterson/</a><br> --000e0cd2c14a70f1340460fb15d9-- --===============0757291257== 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 --===============0757291257==--