From: Chris Bayes (chris@bayes.co.uk)
Date: Wed Dec 12 2001 - 16:27:21 CET
-----Original Message-----
From: Palmovka [mailto:webmaster@aq-web.cz]
Sent: 12 December 2003 15:12
To: chris@bayes.co.uk
Subject: could u forward to transquery pls ? i cant access list
Original Message -----
From: Bryan Rasmussen <bry@itnisk.com>
> >>I thought that exsl:document provided what you wanted with "save"
> >>functionality. I would be comfortable with saying that a database
> >>environment (or document repository environment, whatever) only has
> control
> >>over its own environment--that queries that use exsl:document will
be
> scoped
xsl:document will come around and be abused and used in whatever way, i
am all for a rich environment of open standards; but xsl:document will
be from the xslt authors point of view; transquery brings a hook from
the outside worlds point of view.
> >>to this environment and will create documents in the database. If
you want
> >>to create documents on the filesystem, then use another XSLT
processor (or
> >>at least another processing model). I guess I might not understand
what
> >>possible contradiction you're seeing.
>
> Well it's just a matter of personal taste in how I'd want to program
against
> a Transquery Database.
i would liken Transquery as the ODBC ( ok not so lofty, and no
comments...hehe ) of the xslt world, allright this may sound stupid....
its analogous to when people use old processes within new processes so
they are familiar......but at some point the old process atrophy away (
no more faxing ! ), transquery to me addresses an 'in between' or
migration solution to more sturdier achitectures.
for adoption transquery needs simple mechanisms, which if i go back to
the spec ( nearly a page long ! wow) and see an immediate implementation
by a 3rd party, things look heartening. I am now adding transquery hooks
into my framework which addresses a certain data grey area which is data
locally stored in many places on the operating system the framework
lives in; having a SOAP server and client may be nice but its a golden
hammer in this case ( esp when the client and server are the same box ),
and brings a skillset and requirements of a much larger spec.
> If I'm accessing the Database from my chosen server-side environment,
let's
> assume an .asp or .jsp page, then I thought it could work to my
advantage if
> I could query the database, get a document returned, and use the
document to
> output something into the filesystem, obviously could do that from the
.jsp
if the filesystem had a simple transquery hook then life gets cool
indeed.
> or .asp, but I figured it would be easier declaring a path using
> xsl:document. Possible uses, creating an RSS newsfeed, RDF description
of
> different data accessed on the site, but residing in the database. I
guess
but that would occur within xslt in any event, as u suggest in the next
sentance.
> I'd just prefer having, once I'm in the XSL-T, the control from there.
agree
>
>
> >>I'm interested in seeing your response to the non-exsl:document
solution I
> >>alluded to in the last paragraph or two of my email. Being able to
avoid
> >>requiring extensions would be a good thing, I think.
extensions to me when they popup in every xslt processor are good use
cases to direct the future versions of xslt; and with XSLT 2.0 and XPATH
2.0 thats when things start firming up.
> I'm personally agreed that avoiding extensions wherever possible is a
good
> thing, so I was all for the alluded solution. Since this is the group
before
well for one thing, i would like to see a complicated xslt use case that
gets through every processor equally; this will change in the coming
months i am certain.
but essentially building in dependancies is not a problem if one can
transform away from the that dependancy utilizing core xslt
functionality or using native xslt authored functions.
> anyway, now I must work, someone sent us an awful batch job where
every
> element is a child of the root, and they'd like it in
> a table.
yuk .
chow, jim fuller
This archive was generated by hypermail 2.1.4 : Fri Feb 22 2002 - 11:35:58 CET