From: Evan Lenz (elenz@xyzfind.com)
Date: Thu Dec 06 2001 - 17:02:43 CET
Bryan Rasmussen wrote:
> I don't want to start a features creep here, but are there any other
methods
> for how xsl-t would interact with a database expected to be put on the
> transquery namespace. Currently have tq:input.
> I was wondering because when you execute a query you're returning a new
> document, lot's of things can be done with this document other than just
> saving it somewhere; on of the things I'd expect would be a chained
> transformation, where the document that you output is itself processed via
> further stylesheets. I'm sure we all do this stuff now in batch processes,
> couldn't there be something like a tq:temp to hold a temporary
> representation of the document for further processing/querying?
I'm certainly willing to discuss other possibilities, contracts, etc., and
I'm glad you recognize the danger of "feature creep", because I think we
should keep this warning posted to our foreheads.
One natural way of piping transformations (if limited and a bit hackish)
would be to insert a stylesheet association PI in the result tree. You could
even parameterize the query with a URI for the subsequent stylesheet.
This is limited in a number of ways. The PI doesn't give you a way to pass
parameters to the subsequent transformation (tq:input could still be
available, just not any other user-defined parameters). It's a lot less
general solution than, say, the Cocoon approach of providing pipeline
declarations outside the instance, though since the PI could be
parameterized, it's a little more detached from the instance (as the
"instance" is a dynamic query result). I don't want to reinvent Cocoon, so
maybe a more limited solution would be a good one.
One advantage of the PI approach is that when you've only got two
transformations, say a "query" followed by a "stylesheet", you could leave
it up to the system to determine whether to perform the secondary
transformation or to let the client perform that transformation.
Being a purist XSLT user, I'd like to think that I can do all I need in one
transformation (even if it requires exsl:node-set()), but there are certain
cases where it just makes more sense to do two transformations, rather than
muddying the one transformation with extra imports and/or parameters.
Perhaps this reflects negatively on the modularity of XSLT. I don't know.
All I know is that it sometimes is much cleaner with two transformations. We
could even limit it to a maximum of two transformations (one for "query" and
one for "styling"). This model may prove a very useful one, though I don't
think it will always be necessary by any means.
Just brainstorming,
Evan
This archive was generated by hypermail 2.1.4 : Fri Feb 22 2002 - 11:35:58 CET