Subject: [CODE4LIB] How to access environment variables in XSL

From: "Doran, Michael D" <[email-masked]>
Date: Fri, 19 Jun 2009 14:44:59 -0500

I am working with some XSL pages that serve up HTML on the web.  I'm new to XSL.   In my prior web development, I was accustomed to being able to access environment variables (and their values, natch) in my CGI scripts and/or via Server Side Includes.  Is there an equivalent mechanism for accessing those environment variables within an XSL page?

These are examples of the variables I'm referring to:
    SERVER_NAME
    SERVER_PORT
    HTTP_HOST
    DOCUMENT_URI
    REMOTE_ADDR
    HTTP_REFERER

In a Perl CGI script, I would do something like this:
    my $server = $ENV{'SERVER_NAME'};

Or in an SSI, I could do something like this:
    <!--#echo var="REMOTE_ADDR"-->

If it matters, I'm working in: Solaris/Apache/Tomcat

I've googled this but not found anything useful yet (except for other people asking the same question).  Maybe I'm asking the wrong question.  Any help would be appreciated.

-- Michael

# Michael Doran, Systems Librarian
# University of Texas at Arlington
# 817-272-5326 office
# 817-688-1926 mobile
# [email-masked]
# http://rocky.uta.edu/doran/

---

From: Jonathan Rochkind <[email-masked]>
Date: Fri, 19 Jun 2009 15:48:12 -0400

There is no way to do that inherent to XSL.  There _might_ be a way to 
do that in the particular environment you are processing your XML.  
Which I guess is a Java XSL processor?  I'd reccommend finding the 
listserv for the Java XSL processor you're using, and asking there. 
There might not be a way to do it.

---

From: "Walker, David" <[email-masked]>
Date: Fri, 19 Jun 2009 12:48:25 -0700

Micahael, 

What XSLT processor and programming language are you using?

--Dave

==================
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu
________________________________________
From: Code for Libraries [[email-masked]] On Behalf Of Doran, Michael D [[email-masked]]
Sent: Friday, June 19, 2009 12:44 PM
To: [email-masked]
Subject: [CODE4LIB] How to access environment variables in XSL

-- Michael

---

From: Kyle Banerjee <[email-masked]>
Date: Fri, 19 Jun 2009 13:02:38 -0700

The low tech way to accomplish this is to use PERL to create the XSLT
on the fly. You can just jam the values directly in or define an
<xsl:variable>

kyle

-- 
----------------------------------------------------------
Kyle Banerjee
Digital Services Program Manager
Orbis Cascade Alliance
[email-masked] / 503.999.9787

---

From: Andrew Nagy <[email-masked]>
Date: Fri, 19 Jun 2009 16:05:06 -0400

If you are using some sort of XSL processor in a programming language (java,
php, ruby) you can "assign" a variable to the xsl file and use the variable
in the file much like you would in any other scripting environment.

You can also go one step ahead and use XQuery which gives you the ability to
access a FLOWR based enviornment where you can declare variables and
introduce some more advanced logic over XSL.

Andrew

On Fri, Jun 19, 2009 at 3:44 PM, Doran, Michael D <[email-masked]> wrote:

> I am working with some XSL pages that serve up HTML on the web.  I'm new to
> XSL.   In my prior web development, I was accustomed to being able to access
> environment variables (and their values, natch) in my CGI scripts and/or via
> Server Side Includes.  Is there an equivalent mechanism for accessing those
> environment variables within an XSL page?
>
> I've googled this but not found anything useful yet (except for other
> people asking the same question).  Maybe I'm asking the wrong question.  Any
> help would be appreciated.
>
> -- Michael
>

---

From: Jon Gorman <[email-masked]>
Date: Fri, 19 Jun 2009 15:23:45 -0500

Hi Michael,

Only have time for a quick response.  Like Jonathan Rochkind said,
there's not really a built in way into XSL to refer to these things
like some other languages. The reason is typically the XSL processor
is used by some other language/system to transform a stylesheet, not
connected directly to the web server.  The cgi example works because
you have mod_perl or something similar to set the variables.  In this
case tomcat and the underlying java programs are going to be a layer
between the web server and the actual XSL sheets.  (There's another
model where you send both the xml and the xsl to the client and the
client transforms it, but that's been problematic iin the past).

That being said, XSL does support parameters that can be passed into
the stylesheet.  I know I've used java-type environments that used XSL
that made sure to pass on any "environmental" and http-based variables
in the stylesheet.  At this point perhaps tomcat and saxon (I'd guess
it's using saxon, maybe xalan) might be more tightly intergrated.

Given the application I would suspect you're using though, I wouldn't
count on those types of variables being passed in.  If they are, they
might not be documentted.  If you poke around the xsl files and they
are, you might see something like xsl:param name="myils:server" or
something..  The trick I've seen with a lot of these that you'll have
to explicitly state the parameter at the top in order to use it.
Various parsers might have a way to have the processor dump out what
parameters were passed into it, but I can't think of any off hand.
Many processors have system-properties, and in fact I think they all
are supposed to implement ...system-property('xsl:vendor').  I seem to
remember some processor extending this function to include some other
properties.

You might also want to look at
http://www.mulberrytech.com/xsl/xsl-list/processor-version.xsl (view
source) for some ideas on how to get a better grip on what XSLT
processor is being used.

(The XSL FAQ is long and a little confusing, but has gret nuggets of
information).
http://www.dpawson.co.uk/xsl/sect2/sect21.html

Sorry I can't be of more help.

Jon Gorman

---

From: Jonathan Rochkind <[email-masked]>
Date: Fri, 19 Jun 2009 16:31:44 -0400

Kinda the point of XSL is simply transforming XML as input into 
something (html, xml, or other) as output.

The "right" way to do this, if you have any control over what's 
generating the XML that is "input" to your XSL, is to have relevant (or 
all) environmental variables included in the XML that's input the XSL in 
the first place.

There maybe other ways that aren't as elegant, as everyone else has 
said, it will depend on your particular environment. Because that's not 
really what XSL is designed to do.

---

From: Andrew Ashton <[email-masked]>
Date: Fri, 19 Jun 2009 16:37:28 -0400

Depending on how you're using the XSL, Cocoon->XQuery->XSL is one option -
although I don't know how Xquery would get access to your environment
variables directly.  But you could use XQuery to stream the values into the
source XML as nodes just like the rest of your data, then deal with them how
you please in the XSL.  You can use an XQuery module to store the variables
in question and import them into whatever XQueries you write.

The problem with this approach is that it locks you into a webapp
architecture that you might not want to deal with, though I'd be curious to
hear recommendations for non-Cocoon implementations of XQuery for webapps.

-Andy

---

From: "Doran, Michael D" <[email-masked]>
Date: Fri, 19 Jun 2009 16:53:28 -0500

Hi Dave,

> What XSLT processor and programming language are you using?

I'm embarrassed to say that I'm not sure.  I'm making modifications and enhancements to already existing XSL pages that are part of the framework of Ex Libris' new Voyager 7.0 OPAC.  This new version of the OPAC is running under Apache Tomcat (on Solaris) and my assumption is that the programming language is Java; however the source code for the app itself is not available to me (and I'm not a Java programmer anyway, so it's a moot point).  I assume also that the XSLT processor is what comes with Solaris (or Tomcat?).  As you can probably tell, this stuff is new to me.  I've been trying to take a Sun Ed XML/XSL class for the last year, but it keeps getting cancelled for lack of students.  Apparently I'm the last person left in the Dallas/Fort Worth area that needs to learn this stuff. ;-)

-- Michael

> -----Original Message-----
> From: Code for Libraries [mailto:[email-masked]] On 
> Behalf Of Walker, David
> Sent: Friday, June 19, 2009 2:48 PM
> Subject: Re: [CODE4LIB] How to access environment variables in XSL
> 
> Micahael, 
> 
> I am working with some XSL pages that serve up HTML on the 
> web.  I'm new to XSL.   In my prior web development, I was 
> accustomed to being able to access environment variables (and 
> their values, natch) in my CGI scripts and/or via Server Side 
> Includes.  Is there an equivalent mechanism for accessing 
> those environment variables within an XSL page?
> 
> I've googled this but not found anything useful yet (except 
> for other people asking the same question).  Maybe I'm asking 
> the wrong question.  Any help would be appreciated.
> 
> -- Michael
>

---

From: "Doran, Michael D" <[email-masked]>
Date: Fri, 19 Jun 2009 17:05:01 -0500

Hi Andrew,

> If you are using some sort of XSL processor in a programming 
> language (java, php, ruby) you can "assign" a variable to the
> xsl file and use the variable in the file much like you would
> in any other scripting environment.

The XSL processor is (I assume) being invoked from within the OPAC's Java program, but alas, I don't have access to the source code (and am not a Java programmer anyway).

> You can also go one step ahead and use XQuery which gives you 
> the ability to access a FLOWR based enviornment where you can
> declare variables and introduce some more advanced logic over XSL.

I'm not familiar with this, but will look into it.  Thanks.

-- Michael

> Behalf Of Andrew Nagy
> Sent: Friday, June 19, 2009 3:05 PM
> web.  I'm new to
> for other

---

From: Jon Gorman <[email-masked]>
Date: Fri, 19 Jun 2009 17:05:12 -0500

Try putting somewhere in one of the xslt pages

<p>
Version:
<xsl:value-of select="system-property('xsl:version')" />
<br />
Vendor:
<xsl:value-of select="system-property('xsl:vendor')" />
<br />
Vendor URL:
<xsl:value-of select="system-property('xsl:vendor-url')" />
</p>

Jon

---

From: "Doran, Michael D" <[email-masked]>
Date: Fri, 19 Jun 2009 17:11:07 -0500

Hi Jon,

> Try putting somewhere in one of the xslt pages

Cool!  Here's the output:

	Version: 1
	Vendor: Apache Software Foundation
	Vendor URL: http://xml.apache.org/xalan-j

-- Michael

> Behalf Of Jon Gorman
> Sent: Friday, June 19, 2009 5:05 PM
> > I'm embarrassed to say that I'm not sure.  I'm making 
> modifications and enhancements to already existing XSL pages 
> that are part of the framework of Ex Libris' new Voyager 7.0 
> OPAC.  This new version of the OPAC is running under Apache 
> Tomcat (on Solaris) and my assumption is that the programming 
> language is Java; however the source code for the app itself 
> is not available to me (and I'm not a Java programmer anyway, 
> so it's a moot point).  I assume also that the XSLT processor 
> is what comes with Solaris (or Tomcat?).  As you can probably 
> tell, this stuff is new to me.  I've been trying to take a 
> Sun Ed XML/XSL class for the last year, but it keeps getting 
> cancelled for lack of students.  Apparently I'm the last 
> person left in the Dallas/Fort Worth area that needs to learn 
> this stuff. ;-)
> >
> > -- Michael
> >

---

From: Tom Pasley <[email-masked]>
Date: Sat, 20 Jun 2009 13:42:26 +1200

Hi,

I see Michael's here too - (he's a bit of a guru on the Voyager-L listserv
:-D).

Michael, if you have a look at the Vendor URL, there's some info there, but
you might also try having a look through some of these G.search results:

site:xml.apache.org inurl:"xalan-j" "system"

- see if that helps any - like to help more, but I've got to go!

Tom

---

From: Godmar Back <[email-masked]>
Date: Fri, 19 Jun 2009 22:31:18 -0400

Running in a J2EE is somewhat different from running in a CGI environment.
Specifically, variables such as REMOTE_ADDR, etc. are not stored in
environment variables that are easily accessible.

Assuming that your XSLT is executed for each request (which, btw, is not a
given since Voyager may well be caching the results of the style-sheet
application), your vendor may set up the XSLT processor environment to
provide access to variables related to the current request, for instance,
via XALAN-J extensions. If they did that, it would probably be in the
documentation to which you have access under NDA.

If not, things will be a lot more complicated. You'll probably have to wrap
the servlet in your own; store the current servlet request in a thread-local
variable, then create an xalan extension to access it during the XSLT
processing. That requires a fair bit of Java/J2EE "trickery," but is
definitely possible (and will likely void your warranty.)

 - Godmar

---

From: "Cloutman, David" <[email-masked]>
Date: Tue, 23 Jun 2009 11:04:34 -0700

I'm in a similar situation in that I've spent the last 6 months cramming
XSLT in order to do output from an application provided by a vendor. In
my situation, I'm taking information stored in a CMS database as XML
fragments and transforming it into our Web site's pages. (The CMS is
called Cascade, and is okay, but not fantastic.)

The tricky part of this situation is that simply grabbing a book on
XPath and XSLT will not tell you everything you need to know in order to
work with your proprietary software. Neither will simply knowing what
language the middleware layer is written in. Specifically, you need to
find out from your vendor what XSLT processor their application. In my
case, I found out that my CMS uses Xalan, which impacts my situation
significantly, since it limits me to XSLT 1.0. However, the Xalan
processor does allow for one to script extensions, and in my case I
_might_ be able to leverage that fact to access some system information,
depending on what capabilities my vendor has given me. So, in short,
making the most of the development environment you have in creating your
XSLT will require you not only to grok the complexities of what I think
is a rather difficult language to master, but also to gain a good
understanding of what tools are and are not available to you through
your preprocessor. 

Just to address your original question, XSLT really is not designed to
work like a conventional programming language per-se. You may or may not
have direct access to environment variables. That is dependent upon how
the XSLT processor is implemented by your vendor. I did see some
creative ideas in other posts, and I do not know if they will or will
not work. However, it is often possible for the middleware layer to pass
data to the XSLT processor, thus exposing it to the XSLT developer.
However, what data gets passed to the XSLT developer is generally under
the control of the application developer.

Here is a quick example of how XML data and XSLT presentation logic can
be glued together in PHP using a non-native XSLT processor. This is
being done similarly by our respective Java applications, using
different XSLT processors, and hopefully a lot more error checking.

http://frenzy.marinlibrary.org/code-samples/php-xslt/middleware.php

In the example, I have passed some environment data to the XSLT
processor from the PHP middleware layer. As you will see, what data is
exposed is entirely determined by the PHP.

Good luck!

- David

---
David Cloutman <[email-masked]>
Electronic Services Librarian
Marin County Free Library 

-----Original Message-----
From: Code for Libraries [mailto:[email-masked]] On Behalf Of
Doran, Michael D
Sent: Friday, June 19, 2009 2:53 PM
To: [email-masked]
Subject: Re: [CODE4LIB] How to access environment variables in XSL

Hi Dave,

> What XSLT processor and programming language are you using?

I'm embarrassed to say that I'm not sure.  I'm making modifications and
enhancements to already existing XSL pages that are part of the
framework of Ex Libris' new Voyager 7.0 OPAC.  This new version of the
OPAC is running under Apache Tomcat (on Solaris) and my assumption is
that the programming language is Java; however the source code for the
app itself is not available to me (and I'm not a Java programmer anyway,
so it's a moot point).  I assume also that the XSLT processor is what
comes with Solaris (or Tomcat?).  As you can probably tell, this stuff
is new to me.  I've been trying to take a Sun Ed XML/XSL class for the
last year, but it keeps getting cancelled for lack of students.
Apparently I'm the last person left in the Dallas/Fort Worth area that
needs to learn this stuff. ;-)

-- Michael

> What XSLT processor and programming language are you using?

Email Disclaimer: http://www.co.marin.ca.us/nav/misc/EmailDisclaimer.cfm

---

From: Godmar Back <[email-masked]>
Date: Tue, 23 Jun 2009 21:24:44 -0400

Let me repeat a small comment I already sent to Mike in private email:
in a J2EE environment, information that characterizes a request (such as
path, remote addr, etc.) is not accessible in environment variables or
properties, unlike in a CGI environment. That means that even if you write
an extension for XALAN-J to trigger the execution of your Java code while
processing a stylesheet during a request, you don't normally obtain access
to this information. Rather it is passed by the servlet container to the
servlet via a request object. If you don't control the servlet code - say
because it's vendor-provided - then you have to either rely on any extension
functionality the vendor may provide, or you have to create your own servlet
that wraps the vendor's servlet, saving the request information somewhere
where your xalan extension can retrieve it, then forwards the request to the
vendor's servlet.

 - Godmar