This is a forwarded message originally posted by Torjborn Gannholm. [-----------------------------------------------------------------------------]
Hi! (Apologies if you've already seen this) First reflections after reading mail-archives for xupdate-dev: As a potential user of xml (and other) databases I definitely agree on applying KISS-principles to this problem. So, what is simple? - XPath and uri:s, because "everybody" needs to know that - XSLT, same reason - SQL, because that is how we did it before (and still do it) 1) Everything can be written as an uri, maybe something like: db_net:my_rdb/[EMAIL PROTECTED]/customer_table[first_name =3D = "John"] could be a reference to the set of all rows in the customer_table that = have first_name field set to "John" in a certain session against my = relational database my_rdb obtained by a db_net connection. 2) What is the difference between a table in a rdbms and a node in the = xml sense (other than that a node is a more general concept)?. For that = matter, what is the difference between a row (or even a field in a row) in a = table and a node? What is the difference between a record-set or row-set or field-set and = a node-set (again other than that a node-set is more general)? 3) If you want to have something like SQL, why not do SQL instead of something new? I could see myself writing something like: UPDATE /local/cart/orders FROM /local/cart/addresses SET order/ship_to/address =3D address WHERE order/@id =3D "12345" AND address/@name =3D "Tom Bradford" AND address/@type =3D "work" where whatever used to be table names are actually uri-references to = nodes (or node-sets for multiple simultaneous updates), and what used to be field-names are relative XPath expressions without node-tests or = predicates. 4) just as well as I could see myself writing in XSLT (transform from = old state to new state, the match and select attributes should be able to = be full uri:s): <xsl:transform> <xsl:template match=3D"/local/cart/orders/[EMAIL PROTECTED] =3D '12345']/shipto/address"> <xsl:apply-templates select=3D'/local/cart/addresses/[EMAIL PROTECTED] =3D "Tom Bradford" and = @type =3D "work"]'/> </xsl:template> </xsl:transform> where the default template for update-processing would be (at least conceptually, in effect it would normally mean "do nothing" for most = nodes): <xsl:template match=3D"* | @*"> <xsl:copy> <xsl:apply-templates select=3D"@* | *"/> </xsl:copy> </xsl:template> 5) Either way, I could be accessing any type of data-source (even = ordinary tables in an rdbms) with either of the above queries, resolving that is = not my problem. The only difference is that in the SQL-case I view a table = or a node(-set) as a table, and in the XSLT-case I view a table or a = node(-set) as a node(-set) in the universe conceptualized as two xml-documents (state-before and state-after). However you do it, the servers internal representation of the data is = bound to be different from my conceptual view of it. Also, the way the server actually processes my request is bound to be different from my = conceptual view of it and it is the server's responsibility to do the job as effectively as possible. The only thing needed to agree on is how that request is made to the server (database). 6) I have looked at the current working-draft of xupdate and it looks = nice and intuitive, very like xslt but with easier ways to do the operations = I want and with some power to shield me from really bad mistakes that = would be possible with straight XSLT. Just my humble view /tobe Torbj=F6rn Gannholm Swedish Customs/IT-division mailto:[EMAIL PROTECTED] -- ___________________________________________________________________ Lars Martin mailto:[EMAIL PROTECTED] XML:DB Initiative http://www.xmldb.org ------------------------------------------------------------------ Post a message: mailto:[EMAIL PROTECTED] Unsubscribe: mailto:[EMAIL PROTECTED] Contact adminstrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ ------------------------------------------------------------------