Lars Martin wrote: > 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. > > 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.
By specifying the query language in this way, it implies that the XML repository needs to be implemented in a specific way. In particular, the server would have to expose the entire repository as a single virtualized document. This introduces two problems. First, in order to not alienate larger companies with existing offerings, we don't want to force too much retrofitting. Second, if it's a virtualized document, then it may as well be a document, in that case, the solution falls neatly under the W3C XML Query charter, and we may as well start working with the W3C in that capacity. My argument is that we are dealing with databases here, and whether they be XML native, virtualized, mapped, or enabled databases, they all fall into the scope of the initiative. A 20 gig file with one CARS element and a million CAR elements in it is just as much an XML Database as Microsoft SQL Server 2000 (though that's a stretch) which is just as much an XML Database as Tamino, Excelon, and Virtuoso, and saying that we expose and interactive with that data in some all-encompassing magical way will hurt this initiative in the long run. Our goal should be to create a query language that is incredibly simple, that is easily implemented, and that does not force an implementor into exposing their data in any other way than they already had. I am willing to bet quite a bit that Software AG, Excelon Corp, Openlink Software, Microsoft, and Oracle will all pose the same argument. > 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. Well... I'm certainly impressed with your credentials, but in as much as I'm not bringing anything that I'm currently working on to the table, I'd ask that everyone else do the same. dbXML has a feature that will automatically perform relational linking, recursively, and on-demand, pulling in external nodes into a master document. This feature would work perfectly with your proposal, but it's an implementation specific feature that shouldn't drive the development of a standard. > 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. Which so-called XML databases? An XML database is an XML database, whether it's native, like ours and Tamino, mapped like SQL Server and Oracle, virtualized like Virtuoso, or enabled like Excelon. The degree to which the XML is utilized and exposed is of little concern, the fact is that they are geared toward the management of massive repositories of data, and unlike content management systems, they will almost always store large sets of like documents. A query language compiled into XSLT and executed against a virtualized document will quickly drag the performance of a large repository into the ground. --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/ ------------------------------------------------------------------
