Hi, On Sam, 30 Sep 2000, you wrote: > See the problem here is 'location of the document'. The query language > needs to support querying and updating sets of documents, and therefore > some form of location is necessary for preparing/retrieving those sets > of documents.
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. 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. The problem is as you already said the definition of the location of your document. You can't unify this definition of 'location'. Do you agree or do you disagree? BTW: If I see this "source" attribute in your proposal I presume you will disagree. > One of the good/bad things with SQL dialects is that the original spec > only defined the ability to perform DML and DDL operations but didn't > define how server-specific logic should be represented or how stored > procedures should be represented internally. Because of that, there > are now a bunch of different SQL dialects implemented by different > databases. I don't think we should be defining an entire stored > procedure language, but I do think we should be able to accomodate a > vendor's implementation within the update language syntax. Ok, I think I got it. > > Hmm, XSLT does exactly what we want to do: transformation of a document or at > > least the content of a document. What is the disadvantage of using XSLT? > > The disadvantage of XSLT is that it doesn't easily lend itself to node > level transactions. If you transform from an original document to a new > document with modified nodes, you have a completely new DOM tree (if > we're talking DOM) which means that either you have to do some serious > delta comparisons to determine what has changed in the source document > sets, which is bad, or you have to completely lock entire documents for > update operations, which is also bad. A language that does not depend > on the transformation of one document to another (especially a > virtualized document) is what we should be trying to produce. Speaking > of transactions... We'll need to accomodate those as well. 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. Now one can write a XSLT stylesheet to translate this XUpdate file to XSLT syntax and this result can be applied on ones document containg the data to update. With this solution you have the problem of your input document and output document which are different. (as already mentioned) We (ozone) want to use an implementation that directly works on persistent XML. Lars -- ___________________________________________________________________ Lars Martin mailto:[EMAIL PROTECTED] SMB GmbH http://www.smb-tec.com ------------------------------------------------------------------ Post a message: mailto:[EMAIL PROTECTED] Unsubscribe: mailto:[EMAIL PROTECTED] Contact adminstrator: mailto:[EMAIL PROTECTED] Read archived messages: http://www.xmldb.org/ ------------------------------------------------------------------
