Florent,
This extension function looks really useful.
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?
The use of the the same variable name for global and local had me
confused for a moment -
but as you say you are updating the examples.
Cheers,
Peter
-----Original Message-----
From: Florent Georges [mailto:lists(_at_)fgeorges(_dot_)org]
Sent: July 21, 2008 08:45
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
Subject: Re: [xsl] Content negotiation in XSLT
Richard Light wrote:
Hi
it seems to me that it would be useful if XSLT processors could
specify in the document() function that what they want is, for
example, application/rdf+xml. Then they could be served the RDF
version of a Semantic Web resource, rather than the HTML "human-
readable" version.
If you want to do that for HTTP accesses (I think that can
be achieved by an HTTP header), and if you are using Saxon,
you can use my HTTP extension for Saxon:
http://www.fgeorges.org/xslt/saxon-ext/
(will be updated soon, in particular the examples).
Regards,
--drkm
______________________________________________________________
_______________
Envoyez avec Yahoo! Mail. Une boite mail plus intelligente
http://mail.yahoo.fr
--~------------------------------------------------------------------
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>
--~--
--~------------------------------------------------------------------
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>
--~--