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

[Rich Thompson <richt2@us.ibm.com>]

I see your point ... mixing these can cause naming collisions with no
guidance on resolving those collisions while keeping them separate allows
the Producer/entity to intelligently process such collisions. This was the
form (2 Property[]s + navigationalState) back several versions ago and
people commented that it seemed the two Property arrays could be collapsed
into one. Any objections to going back to separated requestParameters &
requestMetadata?



                                                                                                                  
                      Michael Freedman                                                                            
                      <Michael.Freedman@        To:       wsrp-wsia <wsrp-wsia@lists.oasis-open.org>              
                      oracle.com>               cc:                                                               
                                                Subject:  Re: [wsrp-wsia] Issue #23: Adding clientParameters to   
                      10/16/2002 01:37           getMarkup                                                        
                      PM                                                                                          
                                                                                                                  
                                                                                                                  



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>


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>