Re: [wsrp] Suggestion to change the newNavigationalContextScope event intoa navigational parameter

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

I like the idea of splitting the key
into two parts (a Consumer supplied key to identify the scope and a Portlet
supplied key to identify when Producer-stored deltas are pushed into navState).
In particular, it cleanly solves the concern we had about the initial page
load not obeying idempotency requirements (i.e. the portlet could change
any state during event processing).

On the process side, we are allowed
to withdraw the spec from the public review, make modifications and then
resubmit it for public review. The one possibility I can see for this still
meeting the target of submitting to OASIS on Oct 15 would be to hold a
TC call next Tuesday to hold three votes:
  1. Witrhdraw pr-02 from the current
public review
  2. Approve a wd-21 as cd-04
  3. Submit cd04 to a 15 day public
review as pr-03

If we can get all the process items
accomplished next week, the 15 day public review on pr-03 would end just
before the F2F. The submission vote could then happen at the F2F. That
gives us a bit less time to get the submission packet together, but it
would still be doable if people have their usage and IPR statements all
in place.

Mary, please correct me if I have misrepresented
some portion of the process.

If people think this is a good way to
go, please respond regarding holding a TC call next Tuesday. If people
are in favor, I will produce a wd-21 with this change by Monday AM.

Rich

Stefan Hepper <sthepper@hursley.ibm.com>

09/14/2006 09:36 AM

To	WSRP TC <wsrp@lists.oasis-open.org>
cc
Subject	[wsrp] Suggestion to change the newNavigationalContextScope event into a navigational parameter

Hi,
when thinking about how to map the event that we introduced in draft 2
on the JSR 286 I still disliked that this event breaks the idempotency
of render and thus is against W3C recommendations. Thus I tried to find
a solution that addresses the use case we had and does not break the 
idempotency for render.

My suggestion is to use a container provided navigational parameter 
(e.g. wsrp:navigationalContextScopeID) to all portlets interested in 
this context ID. This ID would be constant for a current navigational 
context scope and would change if the consumer decides to start a new 
scope (which is currently modeled with sending a new event). The portlet
could then use the consumer provided ID and add its own ID and use this
to manage its part of the nav state.

What do people think about this from the technical side?


Another question is how to get a change into the spec at this stage. I
think we would need to abort our current review and submit an updated to
be reviewed.

Rich, can you tell us what this would require?

Sorry that it took me this long to come up with this idea.


Stefan