From: Florent Georges [mailto:lists(_at_)fgeorges(_dot_)org]
Sent: Monday, July 21, 2008 1:49 PM
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
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.
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--