----- Original Message ----- From: "Lars Martin" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, October 23, 2000 4:03 AM Subject: FW: First reflections
> > 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? A Node is most closely related to a single field in a relational table, however there is a very significant difference in that a node can have both metadata (e.g. attributes) as well as child nodes. This is something that a field in a relational table can not have. > > 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)? The same applies here, it's metadata and hierarchy that are very different from the relational model. If you want to store a hierarchy in a relational database you have to flatten it and map it to tables, metadata must also be mapped. When you retrieve your row set you have to carefully construct your query to reconstitute the original hierarchy. In an XML database this isn't necessary, retrieving the node set is going to retrieve the whole hierarchy under the node as well. > > 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. For some reason there is an expectation that XML specifications should be implemented in XML. I'm really not sure this is a good thing in all cases. Take Quilt for example, the original syntax is similar to SQL and fairly easy to understand but the XML mapping in my opinion is too verbose and ugly. This makes the common interactive SQL interpreter that people are very familiar with from a RDBMS much more difficult to use if you have to type XML for all your queries. But maybe now is the time to move beyond those types of tools and focus on building something better, I don't know. What do other people think? > > 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/ > ------------------------------------------------------------------ > ------------------------------------------------------------------ Post a message: mailto:[EMAIL PROTECTED] Unsubscribe: mailto:[EMAIL PROTECTED] Contact adminstrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ ------------------------------------------------------------------
