[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp-wsia] [I#179] requestParameter semantics unclear
There are a couple of concerns that I have with regards to the current
definition of requestParameters.
The definition you used was:
requestParameters: Name/value
pairs reflected from the query string of
the activated URL. These are the query string parameters the Consumer did not consume by processing them itself. Other name value pairs (e.g. HTTP headers from the client or additional Consumer-supplied data) should be placed in the extensions array It seems to imply that "the Consumer MUST pass any parameters passed as
part of the URL and which it does not use otherwise (???) to the Producer in the
requestParameters array".
I fail to see how the Producer can use this feature. How can the Producer
know which parameters are used by the Consumer and which not? We seem to be
getting to a namespacing question again. I am
questioning the need to support requestParameters
for action routing. In my mind, the Producer can always encode any parameters in
the navigationalState. (otherwise, requestParameters become a separate animal
that looks and feels exactly like navigationalState.)
I am still questioning the need to support <form method="get"> in
general hence I am uncertain about Scenario 2 below.
I am happy to have requestParameters refer only to POSTed elements. This
would read: "the Consumer MUST pass ALL data items transferred to it at the HTTP
payload as a result of a form submission to the Producer in the
requestParameters array". This makes sense for me both from a Consumer
perspective (always everything) and from a Producer perspective (all form fields
are opaque). Otherwise, we get into coordination isssue.
Am I missing something?
Eilon
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC