Lars Martin wrote: > questions: > are the "source" and "xpath" concatentated to provide the complete xpath to > a node? Does this translate to: > local/cart/addresses/address[(@name='Tom Bradford') and > not(@type='vacation')]
No, the source is an implementation specific value that identifies the collection, respository, file, DSN, whatever you want to call it. The source should generally point to a set of like documents (or nodes) so that a sensible set operation can be performed against it. My example uses dbXML pathing, which oddly enough is XPath compatible, but the forward slashes should not be a requirement. The idea is that the source could contain any implementation specific location... SQL Server might have sources like "tempdb.dbo.sometable" and so on... If you had a virtualized document, the source could be though of as the path-prefix, but its real purpose is to isolate like nodes. > > > > > > An insertion example: > > --------------------- > > > > <query> > > <element source="local/cart/addresses" > > xpath="/address" > > replace="true" /> > > <where> > > <!-- element source is the default --> > > <match xpath="/[EMAIL PROTECTED]'Tom Bradford'" /> > > <match xpath="/[EMAIL PROTECTED]'work'" /> > > <!-- this one narrows the target set --> > > <match target="local/cart/orders" > > xpath="/[EMAIL PROTECTED]'12345']" /> > > </where> > > <insert target="local/cart/orders" > > xpath="/order/shipto" /> > > </query> > > > > Is this? > > <xu:append select="local/cart/orders/order/shipto"> > <xu:copy select="local/cart/addresses/address[ > (@name='TB') and (@type='work') > and /local/cart/orders/[EMAIL PROTECTED]'12345']]"/> > </xu:append> If that means isolate all address documents in the "local/cart/addresses" collection where the name is TB and the type is work, and insert those addresses into the order/shipto element of the "local/cart/orders" collection where the order id is 12345, then yes. The only difference being the the pathing would require a virtualized document. The reason I chose to use a full XML implementation was because there is the possibility that a query would need to be dynamically generated or transformed, in which case, keeping everything neat and tidy as an element is probably the best way to perform the task. Using full XML would also reduce the need to perform two parsing passes, one for the XML, one for the more complex full XPathing. Additionally, the match elements can offer a quick cue to any possible indexing systems that the document sets should be reduced, and in the order that they're specified. > At the present time I see value in both approaches, and imagine that > selecting one or the other would depend on the particular problem domain. > For example XEditor *was* designed to operate on documents, particularly a > patient's medical record. This can be done in straight XSLT but is > cumbersome to write and debug. I can obviously see many applications where > operations should be carried out on large collections of documents. I guess > its all a point of view. Does a SQL table correspond to an XML document or a > collection of documents? -- to me there is no one correct answer. There is no correct answer, which underlines the need to be completely agnostic of how and where the implementor stores their data. As far as the dbXML implementation is concerned, a collection of documents really maps to multiple SQL tables joined relationally, where the master row represents the master node of the document in the collection. To others, the entire table may be the document. It shouldn't matter. > Perhaps we should take parallel approaches: develop a robust query-update > language (is this a competitor to Quilt??, or alternatively can > insert/update semantics be added to Quilt itself?) and simultaneously > develop a very simple though admittedly less functional simple update > language. I don't see why not, though the simple update language could just as easily be a W3C chartered project. As far as a competitor to Quilt, I don't know, it depends on how far we want to flesh the logic capabilities out and what other operations we'd want to require. --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/ ------------------------------------------------------------------
