OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-wsia message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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


Due to objections on the proposed resolution, I have returned the isse to
being "Active".

Gil

-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: Wed, October 16, 2002 17:07
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>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC