A reason for not putting the database information into the xslt is to make
the xslt independent of the SRU target. One script accesses a lot of
targets. This makes it easier for different users to have different scripts
for the purposes of, for example, having an interface in a different
language.
I wouldn't like software to be changing a script on the fly because it
destroys the value of caching the script. But you could use different
scripts for different databases.
Where each database is a separate URL and thus probably a separate process,
it is very easy to include the database information in the response.
Bill
-----Original Message-----
From: LeVan,Ralph [mailto:[log in to unmask]]
Sent: 08 August 2003 14:34
To: [log in to unmask]
Subject: Re: Database info in response
Duh! Sorry I'm so dense this morning. Rob is absolutely right; the
database info should go into the xslt. That's much better than putting it
into the code that generates the response.
Ralph
> -----Original Message-----
> From: Robert Sanderson [mailto:[log in to unmask]]
> Sent: Friday, August 08, 2003 7:38 AM
>
> * Change the XSLT to include this information. (This is what I do.)
> Then in your server change the line that says which XSL
> file to use to
> be database dependant. Not very hard as you already have
> the information
> (obviously or you couldn't put it in the response).
> This change could be done dynamically if the XSL file is
> generated via
> (trivial) CGI.
**************************************************************************
Now exhibiting at the British Library Galleries:
Painted Labyrinth : the world of the Lindisfarne Gospels
Until 28 September 2003. Admission Free.
*************************************************************************
The information contained in this e-mail is confidential and may be legally
privileged. It is intended for the addressee(s) only. If you are not the
intended recipient, please delete this e-mail and notify the
[log in to unmask] : The contents of this e-mail must not be disclosed or
copied without the sender's consent.
The statements and opinions expressed in this message are those of the
author and do not necessarily reflect those of the British Library. The
British Library does not take any responsibility for the views of the
author.
*************************************************************************
|