Lars Martin wrote: > I see this XUpdate language as the opposite of XPath. Where XPath applies > read-only queries, XUpdate will apply read-write queries. XPath defines the > query what to search in the document, but not where to find the documents to > query. So why should XUpdate define where to find the documents to update? > The location of the document to update should be defined in the query?
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. > > - A harness for executing implementation-specific logic. 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. > Can you explain this a little bit more? What can I expect from this harness? Can't explain it any more because it's a just a requirement. How it will work has to be hashed out. > 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. > Hmm, how will you ensure the correctness of datatypes? Schema? I'd say validation is a function of the data store itself (whether it be Schemas or some home-grown or extended Schema system), and that we should define exceptional conditions where the data store has somehow not been able to accomodate or produce a sufficient analog for the data types. --Tom -- <name>Tom Bradford</name> <title>Chief Software Architect</title> <company>The dbXML Group</company> <phone>(480) 421-1233</phone> ------------------------------------------------------------------ Post a message: mailto:[EMAIL PROTECTED] Unsubscribe: mailto:[EMAIL PROTECTED] Contact adminstrator: mailto:[EMAIL PROTECTED] Read archived messages: http://www.xmldb.org/ ------------------------------------------------------------------
