In message <40177577E6B94B85953BF378B6E8BA3F(_at_)Sealion>, Michael Kay
<mike(_at_)saxonica(_dot_)com> writes
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.
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 above, deciding
on such an approach would be very much in the hands of the individual
XSLT processor.
Richard
--
Richard Light
XML/XSLT and Museum Information Consultancy
richard(_at_)light(_dot_)demon(_dot_)co(_dot_)uk
--~------------------------------------------------------------------
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>
--~--