From: Evan Lenz (elenz@xyzfind.com)
Date: Fri Jan 04 2002 - 18:44:10 CET
Hi Tom and welcome!
> A while back, I proposed an extension to the XML:DB XUpdate specific
> that would support cross-collection node filtering and selection for
> both retrieval or updates. It's called XSelect, and my writeup about it
> can be found at http://www.tbradford.org/xselect.html
>
> Perhaps some of the brain-spewage I wrote in it can be recycled for
> TransQuery.
Yes, I would especially be interested in hearing your input on the
expressivity of XSLT for update. I know you've previously intimated why you
don't think XSLT is suitable for update. I wonder if what we've been
exploring here informs your opinion in any way.
The XUpdate use case examples I've seen have been helpful in determining the
suitability of pure XSLT for update. Insofar as you can provide more of
these with your experience using XUpdate and designing XSelect, that would
be very helpful.
An important aspect of the "update.xsl" import module is that, if it's
standardized, implementors could black-box much of it, effecting real
updates (as opposed to directly implementing the full copy-delete-replace
semantics). This might fly in the face of traditional database uses, but
data/document management using XSLT (and even XML, I'd argue) doesn't always
fit well with traditional database practices/architectures. The TransQuery
effort hopes to leverage, if not SQL programmers' experience, XSLT
programmers' experience. People write incremental updates in XSLT today.
We're asking if this can't be extended to a larger scale.
Evan
This archive was generated by hypermail 2.1.4 : Fri Feb 22 2002 - 11:35:58 CET