From: Chris Bayes (chris@bayes.co.uk)
Date: Sat Jan 05 2002 - 12:00:23 CET
Evan my isp is down so this might not make it to the list because I'm
using a different email
> 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?
I meant the tq:document function I was using. Sorry for the confusion
;-)
I was experimenting with various functions
Update-replace
Update-insert-before
Update-insert-after
Update-delete
And because of the way it would need to be done all of the changes were
stacked and then serialized when the transform was complete but it got a
bit unwealdy so I stopped playing.
I was playing with it because if you have a large database and you want
to do a lot of little changes then you would need to do multiple little
transforms which might take a long time. Some of which might depend on
previous changes. By using <tq:documents <tq:document you could do
further transforms on the result tree containing the new docs.
With my implementation as it is you can do a secondary transform on the
result of the initial update transform. Which wasn't the purpose of it
to begin with.
>
> 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".
Yes that goes back to wanting to keep tq:input small and simple. But
once you have it you can do what you want with it. Maybe updates are out
of the scope of tq:input but as we see there are many ways of achieving
updates and people are going to want to do them. I guess it is similar
to Jim Fuller wanting to expand the meta document to include access
information. Maybe there needs to be 3 projects tq:input with
tq:documents and tq:database layered above and below.
Ciao Chris
XML/XSL Portal
http://www.bayes.co.uk/xml
This archive was generated by hypermail 2.1.4 : Fri Feb 22 2002 - 11:35:58 CET