Hi Tom, On Son, 08 Okt 2000, you wrote: > Quick Note: I spoke to someone from Software AG at XMLOne regarding XML:DB. I'm > hoping he took our message to those who might be able to generate some real > interest in our project at SAG.
Would be great to see SAG supporting XML:DB. I still have an email conversation with Jonathan Robie (SAG) about this topic. He is very interested in a technical colaboration. But Jonathan as a researcher and developer can neither say nor state if SAG would be interested in supporting our project. > This is certainly better than pure Quilt, but has a couple of flaws, IMO. Jonathan R. was focused on the basics of a XML Query Language not on the XML representation. > First, some of the elements like FLWR and BINARYOPERATION are not incredibly > intuitive. We need to be sure that we define element names that are easily > remembered and can be quickly identified as analogous to past query languages > (notably SQL). +1 > I also think that BINARYOPERATION should be decomposed into separate elements > OR, AND, EQUALS (similar to my previous suggestion). It complicates the schema > a bit, but makes a query much easier to write and digest by a developer. +1 IMO, we can discuss about this with Jonathan R. I will try to invite him to join this mailing list. > Also, If there were an incredibly simple way to represent constants, I'd be more > for that. Have to look at this again. > Other than that, this is a much better place to start. It is still very > document-driven, and better oriented toward the 'virtual world-document' notion, > which I'm completely against. Operations such as the ones that Quilt and XSLT > provide are better applied to a client-side implementation, where aggregating > and document processing should happen. It's my opinion that the server should > have to do very little, and that as much transformation as possible should be > offloaded to the client. Tom, can you explain this "document-driven" word a little bit more? What do you mean by this? What do you call a document? Isn't a document just a virtual container for any kind of nodes or node sets? > 99% of the processing power on the internet is on the User's machine, and > historically, 99% of that machine has been unutilized for the most part. It's > unfortunate that companies have to buy incredible amounts of hardware and > software licenses so that presentation (which is the majority of most web > applications) can be performed on the server side. > > In developing XML database specifications, we really need to think about where > the work should take place. If we can produce specifications (Query languages, > CLI, etc...) that enable us to offload a lot of the grunt work to the client, > while the server is left to deal with only what it needs to deal with (primarily > set operations), then I think we've accomplished our goal. The opportunity here > is to ease bandwidth both in the amount of internet traffic, and in the amount > of processing power that has to be exercised at the server side. That's a major > part of the promise of XML, and so we shouldn't be recreating an architecture > that's been dragging the internet to its knees over the past years. Ok, with your request of an interface for basic XML operations we are back to the discussion about accessing XML content and to operate on this content. So somebody should try to write down all the operations we need so we'll have something to discuss. You mentioned set operations, may be there are addtional operations to think about... > So know that when I'm arguing that our specs shouldn't have this or that > feature, my primary motivation is to keep the server side as lean as possible. > It doesn't mean that I think someone is completely out of their mind, it just > means that my goal is (and our goal should be) to shift the work domain to the > CPUs that are hardly doing anything. > > BTW, the 99% figure was completely pulled out of my butt, but I suspect that > it's close to that. I'm not sure if it is 99% but you're very close. ;-) 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/ ------------------------------------------------------------------
