[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Content negotiation in XSLT
> From: Florent Georges [mailto:lists@xxxxxxxxxxxx] > Sent: Monday, July 21, 2008 1:49 PM > To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx > Subject: Re: Content negotiation in XSLT > > "Rushforth, Peter" wrote: > > I'm curious as to why saxon:serialize and saxon:parse are required > > for the <body> element? > > Should the extension function not be able to avoid their use by > > serializing/parsing the request/response internally without the > > need for the other extensions? > > This extension is aimed to provide HTTP features. And HTTP is not > restricted to XML, it sends and receives text. I'm assuming that saxon:parse is just one aspect of the <body> element since the example assumes that the element contains XML. It would be possible for the <body> element to contain a Jpeg image in the form of base 64 encoding and one would use saxon:base64Binary-to-octets to manipulate or output the actual image. However, what about multi-part content? It doesn't seem like the extension function currently handles this possibility. Looking at the examples I think that a small change in the request/response XML could handle multi-part content. Just wrap the <header> and <body> in a <part> element which takes an attribute for the part's identifier. Andy.
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|