[xquery-talk] XQuery web APIs

Jeff Dexter jeff.dexter at rainingdata.com
Wed May 17 12:10:03 PDT 2006


I commend the effort to standardize this stuff - a library of functions and
a standard model for http responses as XQuery results would be nice for
users and something I'd definitely buy into implementing.

Having said that, while I can appreciate the intent of using processing
instructions to model headers there are a few problems with the approach. 
You can't validate them so "requiring" them to appear as the first items in
a result sequence so they "look" like prolog is a bit of a loose constraint.
If they appear elsewhere, there's not much that can be done, and then do
they still intimate headers (I hope not)?

A "standard" XML format with header and payload seems to me to be a little
more versatile... something more akin to what you had in your blog. Using an
XQuery result like this makes generation, validation and serialization a lot
more clear; a user can better expect what's going to end up as a response
code, header or final web page. I can log it for query purposes, better
harness it for validation during development, etc.

In regards to default values for parameters, there's a bit of a disconnect.
Binding an empty sequence works only so long as an empty sequence is
allowed, and if it's not then a system default is unlikely to be
appropriate. 

Rather, at some point someone has to deploy the XQuery so can't the defaults
be defined at that time? Along those lines it would be quite nice if the API
defined a standard means of deployment...

Jeff Dexter.
www.rainingdata.com

-----Original Message-----
From: talk-bounces at xquery.com [mailto:talk-bounces at xquery.com] On Behalf Of
Martin Probst
Sent: Tuesday, May 16, 2006 11:49 PM
To: Per Bothner
Cc: talk at xquery.com
Subject: Re: [xquery-talk] XQuery web APIs

Hi,

>> And if it returns a value, how does that look? Do you use XML or  
>> rather have a "magic" value?
>
> It actually is a "bare" attribute node, though it could be a magic
> value.

So that's pretty close to Lars Trieloff's idea about embedding  
processing instructions in the return stream. I like the idea of  
returning something that is actually valid and nice in XQuery, magic  
values tend to get messy in my experience.

>> In my local changes I currently use external variables to pass in  
>> parameters from the web request, I get the list of declared  
>> external variables from the query, and bind each one to a request  
>> parameter if the namespace URI is a certain X-Hive URI and the  
>> local name matches the HTTP request parameter name. Writing
>> declare variable $web:req external;
>> seemed somewhat more natural to me than
>> web:get-request-param("req")
>> though the default values have some appeal.
>
> I wish one could supply default values to 'declare variable'.
> Perhaps that might be a worthwhile extension.

Currently I ask for all declared variables in the query and then set  
everyone to something, so if there was no query parameter for  
$web:foo it just gets an Object[0] and you can test for existence: if  
(exists($web:foo)) then $web:foo else $default-val.

> Another idea: $web:req(default-value-expression)

That kind of mixes functions with parameters, no?

Anyhow, if we can get a third implementation aboard it might pay off  
to create a common library, don't you think?

Martin

-- 

Martin Probst
X-Hive Corporation
martin at x-hive.com

_______________________________________________
talk at xquery.com
http://xquery.com/mailman/listinfo/talk





More information about the talk mailing list