[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
[my original reply arrived back here empty - apologies if you get this twice]
Michael,
That approach assumes that these parameters will be understood and acted upon by the server delivering the requested resource. In the use case which started me on this line of thought, a single "abstract" URL stands for a resource. See:
http://www4.wiwiss.fu-berlin.de/bizer/pub/LinkedDataTutorial/
for background. In order to get at a "non-information" resource which is referenced in this way, you have to play the "303 See Other" game to get the URL which references the RDF description of the resource. Therefore Andrew's suggestion of a proxy server to inject an Accept header into the request is the sort of thing you would have to do.
More generally, it occurred to me that it would make sense for XSLT processors to include "Accept: text/xml" in the header when fetching resources referenced by HTTP URLs, given that anything other than XML won't be much use, and this Accept instruction might just change what the server delivers for the better. From what you say below, deciding on such an approach would be very much in the hands of the individual XSLT processor.
Richard
In message <40177577E6B94B85953BF378B6E8BA3F@Sealion>, Michael Kay <mike@xxxxxxxxxxxx> writes
Re: [xsl] Content negotiation in XSLT
Subject: Re: [xsl] Content negotiation in XSLT From: Richard Light <richard@xxxxxxxxxxxxxxxxx> Date: Tue, 15 Jul 2008 10:37:03 +0100 |
[my original reply arrived back here empty - apologies if you get this twice]
Michael,
That approach assumes that these parameters will be understood and acted upon by the server delivering the requested resource. In the use case which started me on this line of thought, a single "abstract" URL stands for a resource. See:
http://www4.wiwiss.fu-berlin.de/bizer/pub/LinkedDataTutorial/
for background. In order to get at a "non-information" resource which is referenced in this way, you have to play the "303 See Other" game to get the URL which references the RDF description of the resource. Therefore Andrew's suggestion of a proxy server to inject an Accept header into the request is the sort of thing you would have to do.
More generally, it occurred to me that it would make sense for XSLT processors to include "Accept: text/xml" in the header when fetching resources referenced by HTTP URLs, given that anything other than XML won't be much use, and this Accept instruction might just change what the server delivers for the better. From what you say below, deciding on such an approach would be very much in the hands of the individual XSLT processor.
Richard
In message <40177577E6B94B85953BF378B6E8BA3F@Sealion>, Michael Kay <mike@xxxxxxxxxxxx> writes
Can XSLT 2.0 do content negotiation? Looking at the Linking Open Data work, 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.
The specification very carefully avoids saying anything about how the processor takes a URI and fetches a resource. It's completely processor-dependent. Many XSLT processors provide basic facilities within the product, and allow callbacks to user-provided hooks (URIResolver in JAXP) if you want to do anything more elaborate.
You're welcome to use query parameters on the URI if you want to pass extra information about what's required.
Michael Kay http://www.saxonica.com/
-- Richard Light XML/XSLT and Museum Information Consultancy richard@xxxxxxxxxxxxxxxxx
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Content negotiation in XS, Colin Paul Adams | Thread | Re: [xsl] Content negotiation in XS, Florent Georges |
Re: [xsl] Content negotiation in XS, Richard Light | Date | RE: [xsl] Closing element required , Michael Kay |
Month |