- From: Matthew Dovey <matthew.dovey@las.ox.ac.uk>
- Date: Mon, 22 Apr 2002 12:54:58 +0100
- To: "Dan Brickley" <danbri@w3.org>, "Robert Sanderson" <azaroth@liverpool.ac.uk>
- Cc: "Sebastian Hammer" <quinn@indexdata.dk>, "Eliot Christian" <echristi@usgs.gov>, <www-zig@w3.org>
> > Can't we do that now by giving a URI in elementSetNames which refers to > an > > XSLT style sheet, rather than dumping potentially very long stylesheets > > dynamically at the server for every request? For retrieval purposes, > > specifying a style sheet and specifying a schema for the record to be > > returned in result in the same outcome -- you get the record in a > certain > > format. > > Seems sensible. For the paranoid amongst us, passing in a sha1 or md5 hash > of the XSLT sheet might help the server decide whether the XSLT was safe > to run. Creeping featurism though :) I was going to say that there was an issue about ensuring that the xsl wasn't tampered with in transit especially if the xsl was stored on a third party server (i.e. could have changed since you wrote the client etc.)... In addition, ut of course wo'n't apply if the client needs to send a XSL transform based on user request (unless the client can also act as a web server), and wo'n't apply if the Z39.50 server cannot access the URI concerned (e.g. if it is behind a firewall which only allows z39.50 traffic and not outgoing web requests). In some ways the above is only of benefit if the URI's are from a list of XSLT's explicitly supported by the server (i.e. are stored or cached on the server). This certainly gets around the problem of sending arbitrary XSL scripts to the server - on the other hand isn't much better than named eSpecs such as 'B' or 'F' (apart from you maybe able to look at the XSLT to work out what you will get, which is an improvement over the current 'B' eSpec) Matthew
Received on Monday, 22 April 2002 07:55:00 UTC