----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, November 07, 2000 5:21 AM
Subject: Quilt and XML
>
> Tom wrote:
> >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.
>
> Looking through Quilt it seems to me that the only queries that *have*
> to be performed by the server are the initial LET and FOR sections.
> WHERE and RETURN could all be done by the client.
>
> The problem with Quilt on this front is that it is designed with an ODBC
> style bridge to the db in mind (I mean where you just send the query as a
> string). We obviously can't palm off work to the client with this
> system. But the LET and FOR sections are really just XPath
> containers so we could simply define some CORBA/XML/... interfaces
> to making XPath queries and let the client parse the entire Quilt
> query and have it send the LET and FOR XPaths to the server and perform
the
> rest itself. Actually, simple URLs would suffice for this.
>
I'm not sure that the assumption about some of the query processing occuring
on the client is one that we can make. Likewise, the idea of pushing
presentation to the client is nice but it only applies where a full PC type
device is involved. It will take quite some time before WAP devices and
other appliance type devices will have the processing power necessary to
handle something like XSL-T or even basic CSS.
> On another note: I was wondering if a standard API for performing
> queries would be within the charter of xml:db? My idea being that if we
> are to palm off most of the processing onto the client then it would
> make more sense to define some IDL than to have an SQL style syntax.
>
We've been talking about this very thing on the [EMAIL PROTECTED] list.
One thing I'd like to clarify, what do you consider the client? Are you
referring to a browser or a more traditional client server type client?
> Obviously the leap wouldn't be that great. LET and FOR could just
> be replaced with an XPathQuery() function that returns an
> XMLGrove or whatever. We could also have an XMLList data type
> via
>
> XMLList list = groveToList(some_grove);
>
> We can then do all of the WHERE, FILTER, BEFORE, AFTER, INTERSECT and
> EXCEPT via the standard list processing functions map, foldr, foldl etc.
>
> Strictly speaking we could just treat a grove as a list by just stepping
> through each node, but I have a suspicion that it may be usefull to
> have two distinct views and convert between them as required.
>
> Does anyone else think this is a good idea? I've gotten a lot of
> ideas on how to set this up:
>
> We could define an XML syntax for language independent transfer of
> code (So we won't just be tied to Java).
>
> To fit well with XML it would have to be side-effect free and so
> on. ie, it would have to be a declarative language - I was thinking
> of it primarily being a functional language with some logic
> constructs.
Can you provide an expanded example to make it clearer what you mean? Maybe
how would you replace a single node deep within a document.
>
> Ofcourse, taking this route would mean that we would have to make it more
> familiar than general functional languages. eg, replace `\x -> ...'
> functions with `forall x {...}'. Do combinators forwards rather than
> backwards - we could even call then pipes to make the concept more
> familiar. Also, would would probably be able to do without
> currying.
>
> --
>
>
> Matthew Parry Bowerbird Computing
> Proprietor "XML tools designed to *your* specifications."
> <[EMAIL PROTECTED]> <URL:http://www.bowerbird.com.au/>
> ICQ#56864663 PO Box 1280 Nowra, NSW 2541, Australia
>
> -
> "There now, didn't I tell you to keep a good count? Well,
> there's and end of the story. God knows there's no going on
> with it now." - Sancho Panza.
>
>
>
> ------------------------------------------------------------------
> Post a message: mailto:[EMAIL PROTECTED]
> Unsubscribe:
mailto:[EMAIL PROTECTED]
> Contact adminstrator: mailto:[EMAIL PROTECTED]
> Read archived messages: http://archive.xmldb.org/
> ------------------------------------------------------------------
>
Kimbro Staken
Chief Technology Officer
dbXML Group L.L.C.
http://www.dbxmlgroup.com
------------------------------------------------------------------
Post a message: mailto:[EMAIL PROTECTED]
Unsubscribe: mailto:[EMAIL PROTECTED]
Contact adminstrator: mailto:[EMAIL PROTECTED]
Read archived messages: http://archive.xmldb.org/
------------------------------------------------------------------
