Lars Martin wrote: > Updating a possibly non-existent attribute (as well as element) is > somewhat difficult, because this is not the use case of XUpdate. > Either one inserts (after|before) or append an element|attribute node > or one updates an existing element|attribute node. Its not possible > (with justifiable expense) to find out whether the selected node does > not exist or a node en route. But we need to know exactly this to > decide whether to create the node (i.e. update with implicite > creation) or not. > > Or did I ignore some other facts?
I don't think so. Note that this sort of "update if present else insert" semantic is not unreasonable when working against a relational database. For example, somebody might maintain a catalog of parts and make it available in XML. I might want to keep a mirror of this catalog (or a subset I'm interested in). I therefore get the XML document, convert it into XUpdate statements, and run it against my database. I want to update existing descriptions and insert new ones. In looking at a data-centric update language to be used against relational data, we've identified the following useful semantics [1]: Strict insert (must not exist) Insert if doesn't exist Insert (if doesn't exist) or update (if exists) Strict update (must exist) Strict delete (must exist) Soft delete (may exist) None The latter (none) is necessary for one of the problems you note -- the node is needed as part of the path to a node to be modified. And, yes, it's expensive. -- Ron [1] This language is somewhat different from XUpdate in that you pass in an XML document and either (a) mark up the document with attributes identifying actions to be taken or (b) pass in default actions for different classes of nodes. It allows the user to specify multiple actions in a single XML document and is written with RDBMSs in mind. For example, inserting a single node into an XML document doesn't map well to an RDBMS, as it maps to inserting a row with a single, non-null column, which might not even be allowed. The idea is to pass in complete rows' worth of changes at a time. The language is still being designed and I haven't made a strict comparison to XUpdate, but I suspect the following are true: 1) The language is largely a superset of XUpdate. It probably isn't a strict superset, though, especially with respect to order. 2) That language probably isn't suitable as a general XML update language due to its relational orientation. Actions tend to be specified on the parent (which map to a row) rather than the child (which maps to a column). 3) It should be possible to map a subset of the language to XUpdate. For more information, see: http://groups.yahoo.com/group/xml-dbms/message/845 ---------------------------------------------------------------------- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe: mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ ----------------------------------------------------------------------
