Lars Martin wrote: > IMO, one XUpdate query should be applied on one or more documents or > at least one ore more subtrees of a document where these documents (or > subtrees) are already known.
An insert is also an update, and insertion of a new Document into a data source has to be performed against the data source and not a document location (since a data source shouldn't be considered a document location in my mind). > You can't apply a XUpdate query where the first line of the query selects the > documents to update and the rest of the query specifies the modifications which > are to be applied on the documents selected above. You can if you're not depending on the update language to be a transformation language. Query criteria should be used to identify the data that will be operated against (whether as a source or target). Once you've narrowed those sets down as far as they can be narrowed, then you perform your operation because it minimizes the amount of I/O and memory overhead that will need to used. A SQL database does the same thing. The difference between a primed operation rather than a sequential transformation is almost the same as the difference between performing an update on a table using indexes rather than a table scan. > The problem is as you already said the definition of the location of your > document. You can't unify this definition of 'location'. But we're talking about locations. The update language needs to be capable of taking narrowed sets of data from multiple source locations, resolving them into a set of nodes and applying that set of nodes in some way to a narrowed target data set. The target data can be narrowed to a single document, but needn't be. > Do you agree or do you disagree? > BTW: If I see this "source" attribute in your proposal I presume you > will disagree. :) > To clearify, I do not want to specifiy the XUpdate tag set _on top_ of XSLT or > as an enhancement of XSLT. This is NOT my intention. The idea was to use the > clear and well-formed XSLT tag set to extract those tags which are needed to > express an update. Ok.. I was hoping that this would be true, and so the clarification is welcome. > We (ozone) want to use an implementation that directly works on persistent XML. That's fine. Direct operations are my goal as well, though the XML we're operating against may not necessarily be persistent (see my explanation of dbXML regarding this). -- <name>Tom Bradford</name> <title>Chief Software Architect</title> <company>The dbXML Group</company> <phone>(480) 421-1233</phone> ------------------------------------------------------------------ Post a message: mailto:[EMAIL PROTECTED] Unsubscribe: mailto:[EMAIL PROTECTED] Contact adminstrator: mailto:[EMAIL PROTECTED] Read archived messages: http://www.xmldb.org/ ------------------------------------------------------------------
