There is a difference between the script Bill refers to and the portal
that I am using, although both can easyly be combined. The portal can
control state, a single XSL stylesheet can't.
In the KB we put this information (only name and url) in every record
because each record can result from a different collection.
I do not have a solution for a single XSL file being used for several
databases that Bill is referring to other than using different windows,
layers or frames for the records and for explain.
Regarding the unrequested stylesheet reference, I see no disadvantages.
The advantages is that this is an easy way to link to a native interface
that might be able to provide more functionality for a specific record
e.g. when the client does not know the schemas mentioned in explain.
>>> [log in to unmask] 8/8/03 4:07:02 nm >>>
> A reason for not putting the database information into the xslt is to
> the xslt independent of the SRU target. One script accesses a lot of
> Where each database is a separate URL and thus probably a separate
> it is very easy to include the database information in the response.
Then process the Explain record for it? But as I said in response to
Theo, this /is/ hard when you don't control the state of the client,
the server, or the protocol.
Otherwise we might as well include the whole ZeeRex file in
(Which is certainly possible, but not a route I'd like to go down)
As far as unrequested stylesheet processing instructions go, I think
should explicitly say that they're allowed, but may be ignored (because
can't prevent clients from ignoring them anyway, and we don't want to
force all clients to implement all of XSL)
,'/:. Dr Robert Sanderson ([log in to unmask])
,'--/::(@)::. Special Collections and Archives, extension 3142
,'---/::::::::::. Nebmedes: telnet: nebmedes.o-r-g.org 7777
____/:::::::::::::. WWW: http://nebmedes.o-r-g.org:8000/
I L L U M I N A T I