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.

We can have both client or server handling the request, but I think that
we should definitely be encouraging the client to handle as much of
it as possible.  What is it about the processing that couldn't be
handled by the client?  From what I've read of Quilt the WHERE and
RETURN clauses are really just performing operations on the NodeLists
obtained by the LET and FOR queries.  All of that could be done by
the client.

   > 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?

Not the server.  I was thinking of both of those views.

   > 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
   > [...]

   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.

I was just considering the query part.  Most of what is done by Quilt
lends itself very well to list processing, which a lot of languages
already have functions for.  If we are going to have a standard
query API then I think that a list data structure should be
included in it.  This would allow us to reduce the size of the
API as well as preventing reproduction of effort.

On replacing Nodes, I had just assumed that the function would take
an XPath to define a range along with the Node tree to replace it
with.

-- 


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/
------------------------------------------------------------------

Reply via email to