> Gannholm Torbj�rn wrote: > > > > Each xml-document is in fact a database, and every database > can be seen as > > an xml-document. > > So the real difference between xslt and xupdate lies in the > specification of > > where the result nodes are to be placed. > > This conversation has been had in the past. In the case of XML > databases, this can be argued either way, but for most native XML > databases, this is certainly not true. For persistent DOMs, > it may be, > but to treat a collection of a few million documents as a single > super-document could potentially have terrible consequences for an > application.
Which terrible consequences can you foresee? In what way is an xml-database not like a big document? However, I do more and more like an idea you, Tom, had earlier, to be able to specify the base or source we are working from, e.g. <xupdate:modifications base="/products/[EMAIL PROTECTED]'12345']"> would specify that all modifications are restricted to lie within that specific node, to limit the damage, so to speak. > > > The more I think about it, the more I believe that xslt and > xupdate should > > be identical, with the small difference that in xupdate the > result is not an > > entirely new document but modifications to an existing document (or > > database). > > One of the reasons XUpdate was decided upon rather than a > modified form > of XSLT is that XSLT is a transformation language. It will take a > document and translate it into an entirely new document. > XUpdate is an > operational language that modifies a DOM in-place, which is very > important for the performance of transactional capabilities of XML > databases. Yes, xslt was designed as a transformation language to create new documents. However this is not the first time in the history of the world that one can find a new use for an existing tool. Even xml has turned out to be more useful than was first imagined when creation of it was started. Xslt is in fact just as powerful as a general programming language. I am saying that there is a difference between xslt and xupdate, but the difference need only be in where the result nodes are placed. > > > This difference is easily covered by using the <xupdate:update>, the > > <xupdate:insert-before>, etc. where one in xslt simply > would have had an > > <xsl:element> or a literal result element. In xslt version > 1.1 one can also > > produce multiple output documents with the <xsl:document> > tag. This is a > > very nice analogy to xupdate producing (or modifying) nodes > (each node is > > sort of a document) in a database (which is sort of a > document, too, only > > bigger). > > The applicability of XSelect has two faces. First, as a simple, > generalized replacement for XQuery-ish retrieval in the context of an > XUpdate processor like Lexus, Second for producing node graphs to be > used in XUpdate modifications. > > > Conclusion: no special select is needed, the functionality > already exists in > > xslt in a xsl:value-of. > > I argue this conclusion, especially considering all of the effort that > has been put into XQuery by the W3C. If a special select method isn't > needed, Jonathan and all of the guys pouring their hearts into XQuery > should just pack it up and go home. Sad, but probably true, or at least: they might only need to specify very few additional tags. Unless one uses some other viewpoint in XQuery instead of input nodes and node-sets and result nodes and node-sets. /tobe ---------------------------------------------------------------------- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe: mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ ----------------------------------------------------------------------
