Re: [wsrp-wsia] Issue #23: Adding clientParameters to getMarkup

[Michael Freedman <Michael.Freedman@oracle.com>]

If I understand the proposal correctly clientParameters in MarkupParms carries three forms of data: a)
non-navigational state parameters the producer encoded in the URL via the clientParameters token. b)
client request header values such as device info/user agent/etc. the consumer chooses to pass through to
the producer c) consumer specific request values the consumer chooses to add to qualify this request.  I
believe that the information from (a) shouldn't be mixed with (b) and (c).  A simple argument is neither
the consumer nor the producer should have to worry about avoiding naming collisions in this field.  If
the field only carries (b) and (c) then it only carries information controlled by the consumer.  The
name collision issue is avoided.  Another argument focuses on the use of the data.  Presumably the
producer data (a) is request data.  Generally, the client/consumer parameters (b) and (c) provide
meta-data about the request.  Http separates these (headers/body or query string), we should as well.
So sticking with the mechanism as its defined I would suggest MarkupParms receive 3 fields [make up
names you like]: navigationalState, requestParameters, and requestMetadata.  The first corresponds to
the navigationalState carried in the request.  The second corresponds to all the other request
parameters that are part of the request but not marked as navigational state and the last corresponds to
the client requestHeaders/consumer added state.
     -Mike-




Rich Thompson wrote:

> 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>