I forward this message to the list because Jonathan is subscribed from a different email address and so his posting was bounced by majordomo.
------------------------------------------------------- Tom Bradford wrote: > Jonathan Borden wrote: > > > > the one thing i would like to see is an > > <xupdate:update-or-insert select=".."> > > alternatively we can also include an > > <xupdate:choose><xupdate:when ...>..<xupdate:otherwise..> > > construct. > > This all seems very document-centric to me. Database operations are > typically performed on sets of objects, not single objects, and they > only become single objects when the participating data sets are narrowed > into a single object through criteria. A database that can't perform > set operations with a single call is of little use to anyone. this is just something I find useful for the type of database, repository, document, whatever operations we need to perform. The "select" is a select, no more, no less, so it does work on NodeLists, or sets, assuming that is what the select returns. > The > reason why relational databases are so powerful is because I can > conditionally update or delete a million records with a single line of > SQL. I dunno, maybe I misread something here. That's why "update-or-insert" otherwise you can easily do an if-then-else inside of a for-each. This operation obviates the need for an explicit loop. > > > Also, the remainind construct in XEditor which I find useful is the > > "path-prefix" attribute, the reason this exists is to allow the XUpdate > > operation to take place on a specified subtree of the main document > > specified by the path-prefix value which is prepended to the generated > > XPaths (see http://www.openhealth.org/editor/editorgen.xsl for usage. > > > > 1) this attribute is optional > > 2) when the document to be updated does have a deep hierarchy > it simplifies > > the update list. > > Think of it this way: suppose the entire world is in a huge XML > document, > > path-prefix allows the update operation to be carried out on a > particular > > well defined location within what is otherwise a morass. > > I can't buy into the argument that the world is one big XML document. i've heard both sides of this argument many times. but since I've defined a grove representation for XML, URIs and MIME (see http://www.openhealth.org/XSet) I am entitled to my viewpoint. The other side of this argument would state that so-called XML databases don't really have much to do with XML itself which defines a *syntax*, so in the same way that we might provide a DOM wrapper on a database and call this an XML database, we might also provide a DOM wrapper on a MIME message, or a directory/filesystem or anything else that is specified by a URI. > Most XML Databases will provide functionality for pulling in XML from > non-XML data sources, and the locations of these legacy data stores, > won't fit into the XPath specification. Err... no! see above. A path prefix can definitely > apply to a document-rooted XPath, but if you extend the notion of what > the prefix can contain into the realm of heterogenous data stores, you > can no longer encapsulate that data cleanly with an XPath. Again, see above. The XSet specification explicitly allows non-XML data to be transformed and generally operated upon via SAX,XSLT and other 'XML' software. > > The W3C has a lock on the document, and the XML Query Language charter > will ultimately cover document-centric querying and updating, but it > doesn't address any of our issues as developers of XML databases. I > think our goal here is to think beyond the document into how terrabyte > repositories of XML should be managed and queried. I agree. Specifically I consider XPath as a subset of a general URI (to be more specific an XPointer allows URIs to be created from XPaths), so the path-prefix allows such operations ***as if*** we are operating on a single document (document being an entirely logical entity and not necessarily a single physical file). The bottom line, however, is that path-prefix is an optional attribute, and you don't need to use it if you don't wish to. Jonathan Borden The Open Healthcare Group http://www.openhealth.org ------------------------------------------------------------------ Post a message: mailto:[EMAIL PROTECTED] Unsubscribe: mailto:[EMAIL PROTECTED] Contact adminstrator: mailto:[EMAIL PROTECTED] Read archived messages: http://www.xmldb.org/ ------------------------------------------------------------------
