From: Bryan Rasmussen (bry@itnisk.com)
Date: Fri Dec 07 2001 - 10:14:32 CET
>>I'm glad you recognize the danger of "feature creep", because I think we
>>should keep this warning posted to our foreheads.
I for one would be glad for a specification that fills no more than 25
printed pages.
I can currently just see three extremely useful transquery methods, input,
temp(or pipeline, whatever), and save, with save b eing used to create a new
document set. Of course xsl:document or exslt:document could be used for
that, but then the database would have to support a method for using those
elements to write to the database.
>>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.
Well I like to think that I can do all I need in one transform as well,
however I've found sometimes I don't like to do that,for the same reasons
you've stated.
>>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.
I just think it implies that XSL-T or technologies based on it should
reflect this pipeline transformation style. One of my pet theories is that
technologies are most important in how they are misused, not in how they are
originally conceived, because the misuse demonstrates where some of the
burning needs are for new technology. Cases in point:
1. The misuse of html tables for styling indicated the need for a styling
solution.
2. The misuse(I consider it a misuse) of relational databases to serve
essentially static pages(I just don't think they're really dynamic if they
don't change) to multiple users, indicates the need for content/document
management on the web, which I suppose is what a lot of people on these
lists use xml for.
3. The misuse of SOAP(originally a remote procedure technology), as a
messaging technology.
>>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.
I like that, if someone needs more I suppose they could programmatically add
the generated document to a new database(or through a save method discussed
above) and then query against it. The best thing about it is it allows more
advanced XSL-T developers to write the queries, formatting the output into
an xml format that the less advanced can then style. Modularization of work.
Original message
> 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?
This archive was generated by hypermail 2.1.4 : Fri Feb 22 2002 - 11:35:58 CET