- From: Jeni Tennison <jeni@jenitennison.com>
- Date: Tue, 08 May 2007 16:17:41 +0100
- To: public-xml-processing-model-wg@w3.org
Alex Milowski wrote: > In the case of making an HTTP request, the URI and other aspects of > making the HTTP request often aren't configuration parameters. Certainly > in the REST architecture, you need to dynamically formulate the > actual request from some set of input XML. As such, there is very little > that easily maps to a simple option without severe limitations. I think you're saying that if the values that are used in options originate from XML documents then the step should be configured using XML rather than options. I thought that was the point of allowing <p:pipe> etc. within <p:option>: to set the value of an option from an XML document. > The current input and output document representation maps directly > to the HTTP protocol specification. You can't map HTTP to a finite > set of name/value pairs without making decisions that seriously > limit functionality. HTTP headers are name/value pairs. There are standard HTTP headers that could be options. Extension headers can be catered for using parameters. How would that limit functionality? Jeni -- Jeni Tennison http://www.jenitennison.com
Received on Tuesday, 8 May 2007 15:18:13 UTC