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







The means by which you encoded the product-id into the navigationalState
would be valid as things stand now. The key question Mike has raised is
whether this type of encoding should be required of entities and therefore
extraneous query string parameters become invalid (i.e. Consumer may throw
them away). My response was to question what value would be gained (or
problem avoided) by eliminating this flexibility for entity developers. I
agree that developers will often encode what used to be query string
parameters into their navigationalState (most impact bookmarking), but why
should the protocol require they do so for all parameters?

Adding such a requirement would not eliminate clientParameters as it
currently contains information from transport headers, Consumer data stores
and extraneous query string parameters.



                                                                                                                  
                      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 12:43           getMarkup                                                        
                      PM                                                                                          
                                                                                                                  
                                                                                                                  



Shouldn't the product-id=333 be part of the navigationState itself?

I.e., something like (for example):

http://ConsumerURL?wsia:navigationState=shopbskt54,product-id=333

(Encoded in an Entity-dependant manner)

Would this eliminate the need for clientParameters?

In the scenario below, if the information is not encoded as part of the
navigational state, but rather as extra parameters, wouldn't it cause
the user, after a refresh or a bookmark, to return to a different
product page, because the product id is lost?

Or, is the idea in client parameters based on the assumption that these
parameters are part of an implicit contract between the Producer and the
Consumer, so the Consumer may inspect and change parameters as part of
the protocol?

If so, wouldn't this invalidate the plug-and-play assumption? (I.e., if
the Producer changes the way it handles parameters? I.e.., this becomes
a screen-scraping scenario)

Do you see this any differently than the Consumer changing the actual
navigationState? I.e., If an Amazon product page URL is
http://www.amazon.com/products/333/display - then the Consumer would
have to scrape the URL to change things?

Eilon


-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: Wednesday, October 16, 2002 11:58 AM
To: 'wsrp-wsia'
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>





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