[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp-wsia] [I#179] requestParameter semantics unclear
I think requestParameters currently exists for legacy content providers and those using method=get. Rich Thompson Eilon Reshef <eilon.reshef@webc To: wsrp-wsia@lists.oasis-open.org ollage.com> cc: Subject: RE: [wsrp-wsia] [I#179] requestParameter semantics unclear 12/11/2002 08:14 PM 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 -----Original Message----- From: Rich Thompson [mailto:richt2@us.ibm.com] Sent: Tuesday, December 10, 2002 2:31 PM To: wsrp-wsia@lists.oasis-open.org Subject: Re: [wsrp-wsia] [I#179] requestParameter semantics unclear Current spec language: 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. This certainly covers the first 2 (action URLs and method=get both use query strings). We may want to expand it to include the third as well. Could not a .Net Producer just supply the same values for both APIs? Rich Thompson Gil Tayar <Gil.Tayar@webcol To: wsrp-wsia@lists.oasis-open.org lage.com> cc: Subject: [wsrp-wsia] [I#179] requestParameter semantics unclear 12/10/2002 03:18 AM Issue: 179 Status: Active Topic: interface Class: Minor_Editorial Raised by: Eilon Reshef Title: requestParameter semantics unclear Date Added: 10-Dec-2002 Document Section: v0.85/5.1.6 Description: "requestParameters: I am not sure what the intent of this variable is. it can mean three different things: 1. Data items passed as part of the action URL - this seems redundant as the Producer can easily use navigationalState. 2. Data items passed as <form method=get> submit? Is this indeed the case? 3. Data items passed as <form method-post> submit? Is this indeed the case? Note that (2) and (3) are accessed using the same API in J2EE but not in ASP, so if the intent is also for (2) and (3) then we may need to differentiate." ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC