Chris Tomlinson <chris@xxxxxxxxxxxx> wrote:

>Is there any intent that XSL (including the filter extensions in XT) be
>able to handle source documents that have markup intended to perform
>dynamic generation of a portion of the content. What I mean is something
>like the following:
>
><doc>
>  <title>List of items</title>
>  <!-- produce the items via a query -->
>  <query id="query-1" db="accts-payable" sql="select acct-title, amt
>from accounts where ..."/>
></doc>
>..

A system I'm working on may be similar - XML documents which contain
embedded queries (encoded using XML, as yours are).  Our approach is:

- on receiving an HTTP request for the document,
  locate & read the XML document from the filesystem
- using the DOM, find the query nodes in the document and issue 
  the SQL based on their contents
- the SQL results generate new XML elements (the structure/names of
  which are described as part of the query 'block') which replace
  the query element in the XML tree of the document
- the XML document tree is then transformed by XSL into HTML
- the HTML is delivered

The adavantage of not doing the SQL processing in the HTML is
that when clients can routinely do the SQL translation for 
themselves we won't have to worry about the implications of their
browsers trying to issue SQL commands to our database server.

A disadvantage of the above approach is that any XML document
may be rendered in many ways, depending on the stylesheet.  Some
stylesheets may not be interested in rendering the elements
created by our database lookup, in which case we've wasted effort
looking them up.

Maybe the decision on whether the database lookups should be 
performed can be determined by parameters on the HTTP request
 that initiates the process.

We were tempted to perform the lookups from javascript invoked
from the stylesheet, using <xsl:eval> (we're using the MS IE5
 beta), but:

a) it didn't work - we couldn't create the necessary objects from the 
   javascript environment running under MSXSL (I think the run time
   complained along security lines...)
b) it wouldn't allow us to sensibly offload the XSL processing to
   the client when that happy day arrives.

Kent Fitch                           Ph: +61 2 6276 6711
ITS  CSIRO  Canberra  Australia      kent.fitch@xxxxxxxxxxxx



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list