> > Thing is, in XSLT, every node is a result node, because the processor > regraphs everything. The model is a pipeline because of the > language's > original goals. In XUpdate, only modified nodes are new, > allowing only > differences to be applied to existing graphs. Different model, for a > different purpose. >
Right, I think we are basically in agreement. I do NOT want to do an xsl-transform against the database either. However, when most of the relevant commands that we need already exist in a language that everyone that uses xml needs to know, then we would be silly to invent new names for the same commands or different ways of expressing what we want to do. Every node that is changed in an xupdate needs to be created as a result-node in some way. Creating one or more result-nodes is just what the xslt commands do. The flow in xslt where you start by recreating the whole document is not suitable for xupdate, so the actual flow would be different in an xupdate-processor. What we need specifically for xupdate is a way to specify where the result nodes are to be created. The actual creation of the result nodes can mostly be done with the commands that already exist in xslt, combined with a way to select nodes from the db. What is more logical than a tag containing the specification of which node is to be updated enclosing the commands (or literal elements) for creating the result-node? Any good database would do some internal processing of the commands (be it SQL or XUpdate) to make the operation efficient. The great problem with xml is that because of its origins there is sort of a document-centric view already in existence. So, for example, sax-processors usually imagine that there always is a text source-document for the xml, which should not have to be true. That xml should always come in documents is not a fact of nature, it is just a limitation in our minds because of the origins of xml. I am perfectly happy to see the world as one large xml-node, although preferably I have some way to restrict myself to specific sub-nodes at appropriate times. However, no element-node is any more qualified than any other to be thought of as a root-element in the right situation. A document is just one possible way to store/transmit an xml element-node, so the concept of a document should really be peripheral to xml, as just one type of container for xml. The standard for an xml document is still an important concept, but it should definitely not be a basic block in an xml-db. I would like to be able to select nodes freely from the db and present the result as a document, but that is another matter. To update an xml-tree we have input nodes, whether from db-selects or xml-text-documents or even objects that act as if they were xml-nodes (for example we can have an object-parser that generates sax-events), and from these we generate result nodes that are to be placed into an existing xml-tree, whether it be an actual db or an xml-text-document or even an object that understands how it is to update itself from the result nodes (via some parser). I believe that what we are trying to do here is to create a standard way for the users to communicate their intentions to the database application (or a text-file handler or whatever). The actual processing is the problem of the database vendor and is of no real interest to me as a user, so keep the basic design of dbxml or Tamino out of this discussion and solve that problem internally. If the vendor cannot make it easy and efficient for me and other users, then RIP. Easy and efficient means that I can think "xml-like" and also "xslt-like" and preferably not even have to care that I am actually using a database rather than just a text-file or some other conceptual xml-tree because there is no real difference between these things from an xml usage viewpoint. /tobe ---------------------------------------------------------------------- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe: mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ ----------------------------------------------------------------------
