From: Evan Lenz (elenz@xyzfind.com)
Date: Fri Jan 04 2002 - 21:53:23 CET
Chris Bayes wrote:
> > Oh, are you saying that tq:document() does its work via side
> > effects? Interesting... Ultimately, I think we'll want to
> > avoid side effects!
> >
> Well if an empty string is a side effect... Let's face it an update
> query will have rather large side effects on the database.
Yes, that's true, but the tq:document approach restricts the side-effects to
happening (at least conceptually) *after* the XSLT transformation is done.
That is, the update directives can be read from the result tree outside of
the transformation, rather than hooking inside the transformation itself.
This ensures flexibility of processing models, e.g. if I want to serialize a
small add/replace directive over the wire (of course, all bets are off on
generated-ids in that case, but so are they on relative URIs, etc.).
> I prefer this new solution because it avoids the need for tq:document
> but I can't get around not using tq:baseURI
I can understand not being able to make generate-id() work using MSXML, but
did you mean "exsl:document" in the above sentence?
Your experimentation points out the problem that generate-id() might not be
workable using existing XSLT implementations. Of course, for database
updates, existing implementations probably won't work anyway. We may want to
factor update out of TransQuery input. If TransQuery input is useful by
itself in the context of simple stylesheets and other applications such as
Schematron, then it would be nice to keep that independent from "TransQuery
update".
Evan
This archive was generated by hypermail 2.1.4 : Fri Feb 22 2002 - 11:35:58 CET