Lars Martin wrote: > just for your interest, I got this paper from Jonathan Robie from SAG. May be > we can accomplish the two approaches of Quilt and XUpdate to develop the new > update specification.
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. This is certainly better than pure Quilt, but has a couple of flaws, IMO. 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). 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. Also, If there were an incredibly simple way to represent constants, I'd be more for that. 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. 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. 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. --Tom ------------------------------------------------------------------ Post a message: mailto:[EMAIL PROTECTED] Unsubscribe: mailto:[EMAIL PROTECTED] Contact adminstrator: mailto:[EMAIL PROTECTED] Read archived messages: http://www.xmldb.org/ ------------------------------------------------------------------
