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







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