[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp-wsia] Issue #23: Adding clientParameters to getMarkup
Because the Consumer is an intermediary with responsibilities to manage returning navigationalState across invocations regardless of whether it pushes them into the URL, the actual parameter named wsia:navigationalState becomes an encoding of various things the entity might have put on the URL if the access had been direct rather than through an aggregated page. In other words, your URL likely becomes http://ConsumerURL?wsia:navigationState=shopbskt54&product-id=333. The semantics currently in the spec have the Consumer inspecting the activated URL for parameters it should process and then passing any remaining query string parameters on to the Producer (who may further filter it before the entity sees it) in the clientParameters Property[] (Should we explicitly say that the Consumer should mark all parameters where it doesn't know the type as xsd:string?). Eilon Reshef <eilon.reshef@webc To: "'wsrp-wsia'" <wsrp-wsia@lists.oasis-open.org> ollage.com> cc: Subject: RE: [wsrp-wsia] Issue #23: Adding clientParameters to 10/16/2002 11:24 getMarkup AM How does the Consumer distinguish between part of the URL that's a true navigational state and a client parameter? E.g., if the navigational state is http://www.amazon.com/products?product-id=333 Is the product-id a navigational parameter or a client parameter? What's the distinction between the two? --Eilon -----Original Message----- From: Rich Thompson [mailto:richt2@us.ibm.com] Sent: Wednesday, October 16, 2002 11:07 AM To: wsrp-wsia Subject: Re: [wsrp-wsia] Issue #23: Adding clientParameters to getMarkup I don't care much about the name of this parameter, but wonder what entity developers would think "qualifyingParameters" means. As to this carrying query string parameters the Consumer does not process, to me this is a natural way to deal with vendor extension on what the Consumer recognizes/processes; anything this particular Consumer does not recognize is just passed on. It also makes a nice distinction between navigationalState (i.e. bookmarkable state) and transitory parameters for use just on this invocation. What is the problem you foresee with this including extraneous query string parameters? Michael Freedman <Michael.Freedman@ To: wsrp-wsia <wsrp-wsia@lists.oasis-open.org> oracle.com> cc: Subject: [wsrp-wsia] re: Issues for 10/7 10/15/2002 06:53 PM There are few issues this week that have been marked to move from tentative to resolved that I don't think are ready yet. Here are the comments for those issues: Issue #23: Adding clientParameters to getMarkup The resolution is too general. I suggest we tighten the definition/usage of clientParameters to merely mean the non-query string data that qualifies the request. I.e. the equivalent of what's carried in the http request headers (though because we are consumer mediated, it this information is client + consumer data). What I object to in the resolution is that it carries query string data. This is not information that portlets should encoding in their URLs. Finally, I think we should rename this field maybe to something like "qualifyingParameters". This field carries more than client headers. -Mike- ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- 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