Hi Tom, thanks for the precise description of your proposals. I think I'm on the right way to understand your ideas now.
On Sam, 30 Sep 2000, you wrote: > An insert is also an update, and insertion of a new Document into a data > source has to be performed against the data source and not a document > location (since a data source shouldn't be considered a document > location in my mind). I agree. In our current implementation the insertion of new a document is specified by an API, as well as the identification of source locations. Now I agree that this must be possible via autonomous XUpdate queries. But this requirement results in the requirement of an unified XML database interface, described below. > You can if you're not depending on the update language to be a > transformation language. Query criteria should be used to identify the > data that will be operated against (whether as a source or target). > Once you've narrowed those sets down as far as they can be narrowed, > then you perform your operation because it minimizes the amount of I/O > and memory overhead that will need to used. A SQL database does the > same thing. The difference between a primed operation rather than a > sequential transformation is almost the same as the difference between > performing an update on a table using indexes rather than a table scan. As written above, currently we do this narrowing to the data source _before_ executing the XUpdate query. That's why I was against the definition of a 'source' attribute to identify the data source. > > The problem is as you already said the definition of the location of your > > document. You can't unify this definition of 'location'. > > But we're talking about locations. The update language needs to be > capable of taking narrowed sets of data from multiple source locations, > resolving them into a set of nodes and applying that set of nodes in > some way to a narrowed target data set. The target data can be narrowed > to a single document, but needn't be. But then your implementation of XUpdate needs to know how to retrieve these souce locations (in most cases this will be documents, IMO) from the underlaying data source. So this implementation won't be independend from this data source - and so you can't exchange this implementation with an other (may be better, cheaper or whatever) implementation. So far there is no standard how to retrieve and store XML trees from a data source - as the ODMG specification defines this for object databases. For the Prowler CMS we have introduced a XMLDatabase (or XMLResource) interface (based on nodes instead of objects) that one can see as the counterpart to the ODMG specification. Without such an unified interface the XUpdate implementation has to use data source specific API calls! > :) ;-) > That's fine. Direct operations are my goal as well, though the XML > we're operating against may not necessarily be persistent (see my > explanation of dbXML regarding this). Agreed. Lars -- ___________________________________________________________________ Lars Martin mailto:[EMAIL PROTECTED] SMB GmbH http://www.smb-tec.com ------------------------------------------------------------------ Post a message: mailto:[EMAIL PROTECTED] Unsubscribe: mailto:[EMAIL PROTECTED] Contact adminstrator: mailto:[EMAIL PROTECTED] Read archived messages: http://www.xmldb.org/ ------------------------------------------------------------------
