Hallo everyone,

At the moment I provide XML data with XSL stylesheets for the users to browse reporting data. This works fine both/either accessed from a file-server location or via a web-server (without the active involvement of the web-server).

This is the way that we would like to keep it but now I have a question about a 'nice-to-have' feature:

I notice that XSL can use extensions to actively access a database. For example ...

import java.sql.Connection;
import jave.sql.DriverManager;
etc ...

It would be great to incorporate direct sql access to our Oracle database (to retrieve detail data alongside the consolidated XML data) but before I start investigating this further, I wanted to check a couple of basic questions:

- Does such database/sql access require the involvement/setting of the web-server? Or will the XSL engine fire up this functionality independently? Is this the case even if the location of the XML/XSL is a drive on a file-server (rather than on a web-server)?

- Where are these (SQL) extension files/programs stored/installed? And can I run a simple check to see if they are installed/working?

Any tips about database access (via XSL) would be a great help.

Regards and thanks,
Alan Searle.

>I notice that XSL can use extensions to actively access a database.

There's nothing in the XSLT language to allow SQL access. There are extensions available with some products, e.g. Saxon and Xalan. Any questions about the functionality are therefore product-specific.

>Does such database/sql access require the involvement/setting of the web-server?

In the case of the Saxon and Xalan extensions, it relies on the JDBC support in the Java VM, which in turn depends on the availability of JDBC drivers for your chosen database. I've always done this myself through the generic JDBC/ODBC driver on Windows; details for other platforms may vary.

Michael Kay
http://www.saxonica.com/
Author, XSLT Programmer's Reference and XPath 2.0 Programmer's Reference

In my opinion connecting directly to a databse from within XSLT is a poor design. Far more flexible to create some sort of RESTful web service whereby you can access information via a construct such as document('http://myDomain.com/myServices/Customers/123456'). You can build the URL dynamically at runtime based on other data and global parameters etc.

--

Joe (Microsoft MVP - XML)

> In my opinion connecting directly to a databse from within XSLT is
> a poor design.

I agree: My main push is to get as much (consolidated) data as possible stored in XML and presented through XSLT. Data access would only be a nice-to-have.

> Far more flexible to create some sort of RESTful web service
> whereby you can access information via a construct such as document
> ('http://myDomain.com/myServices/Customers/123456'). You can build
> the URL dynamically at runtime based on other data and global
> parameters etc.

The problem that I have with externally linked XML files and the document() command is that this rules out lots of 'key' and grouping functionality which I use quite intensively (consolidation reports).

At the moment, I am trying to get all my data into one (period-based) XML file so that I can use 'key' commands.

Anyway, thanks for your tips: I will be googling on the keywords to see what I turn up.

Regards,
Alan.

I don't see why external documents should necessarily rule out the use of keys. A key is evaluated against the document that owns the context node, or in XSLT 2.0 you can pass a context node, so you change to the external document using xsl:for-each and use your key.

I can see there might be a problem if you want to aggregate across many documents but that's going to be the case using direct database access as well.

--

Joe (Microsoft MVP - XML)