<-prev [Thread] next-> <-prev [Date] next->
Month Index | List Home

RE: [xsl] Content negotiation in XSLT

Subject: RE: [xsl] Content negotiation in XSLT
From: "Houghton,Andrew" <houghtoa@xxxxxxxx>
Date: Mon, 21 Jul 2008 14:53:44 -0400
> From: Florent Georges [mailto:lists@xxxxxxxxxxxx]
> Sent: Monday, July 21, 2008 1:49 PM
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject: Re: [xsl] 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.
Current Thread
<- PreviousIndexNext ->
RE: [xsl] Content negotiation in XS, Rushforth, Peter Thread [xsl] Error: Ambiguous, V.Ramkumar
RE: [xsl] Content negotiation in XS, Rushforth, Peter Date [xsl] Fetch xml from URL in XSL, sudheshna iyer
Month