Gannholm Torbjörn wrote: > > It is nice to be able to do a temporary switching of the input node-context > from the current xupdate-document to "some-other-nodes" to build our > resulting node-set. This is very like the document()-function in xpath, the > for-each tag and apply-templates tag in xslt change the input node-context > and the value-of tag in xslt selects string values from nodes while > xsl:copy-of copies entire nodes/node-sets. > > If we look at xslt, we have one or more source documents generating one new > result document. > In the database case we have one or more source nodes that update nodes in > the db. > 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. > 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. > 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. -- Tom Bradford The dbXML Group, L.L.C. http://www.dbxmlgroup.com/ Desktop, Laptop, Settop, Palmtop. Can your XML database do that? ---------------------------------------------------------------------- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe: mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ ----------------------------------------------------------------------
