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/
------------------------------------------------------------------
