web application spec

I'm investigating the possibility of implementing the request/response 
parts of the webapp specification, and I'd like to propose some (small) 
amendments.

The spec indicates that the HTTP request is supposed to be provided as 
the context item for the evaluation, but is also provided as a global 
variable.  My practice in Lux has been to supply an implicit 
collection() as a context for evaluation, and I think the requirement to 
provide the HTTP request would conflict with that. It seems to me that 
the global variable binding is sufficient to provide applications with 
the HTTP request, and the query context should be reserved as 
implementation-dependent.

Regarding the response; it is currently specified that applications must 
return a web:response element.  I currently allow any value to be 
returned.  If the value is a single node, it is interpreted as the 
response body, status=200; content-type is provided through external 
configuration of the service. This is a nice convenience to have built 
into the service, I think, and doesn't need to conflict with the spec. 
In addition, If a sequence or atomic value is returned, I apply some 
heuristics to arrive at a valid document.

I'd like to amend the specification to indicate that returning any value 
is permissible, but the behavior when the result is not a single 
web:response is implementation-defined.  This leaves the door open for 
convenient implementations, but allows applications to rely on a 
consistent behavior from their container so long as they  use the 
<web:response> element.

Finally I'd like to be able to say I'm complying with the (some) spec 
without implementing the app packaging. This is probably just a 
formality, but it would be nice to have a separate name for these two 
parts of the spec since I believe they are useful independently.  I 
could say that Lux uses the "EXPath http protocol?"

looking forward to your thoughts

-Mike Sokolov

Received on Friday, 13 September 2013 15:25:29 UTC