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

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

This change would delete section 6.11.2
and insert a new section 6.12 (before User categories):

6.12 Defined Public Values
This specification defines the following public values
in the interest of promoting interoperability on a set of commonly encountered
scenarios. All of these are defined within the WSRP types namespace (i.e.
urn:oasis:names:tc:wsrp:v2:types). 

6.12.1 wsrp:navigationalScopeID
This is a public navigational parameters which Portlets
can indicate an interest in by including a ParameterDescription within
their PortletDescription which references wsrp:navigationalScopeID as the
only value within the names field. Consumers MUST supply a unique value
for the wsrp:navigationalScopeID parameter whenever its policy determines
that the scope of the navigationalContext has changed. While the value
of the navigationalContext can change within any one such scope, the changing
of scope will reset both the value and managing of the navigationalContext.
The purpose for this navigational parameter is enabling those Producers/Portlets
which choose an implementation style precluding the Consumer from fully
managing the Portlet's navigationalContext to manage an extension to this
state in a manner consistent with the Consumer's management for other Producers/Portlets
(i.e. use this value as the base of a key for determining the correct extended
state. This key could also include a Portlet defined portion which would
be generated whenever some portion of the extended state is moved into
the Portlet's navigationalContext). While Consumer policy governs when
a new value is generated for wsrp:navigationalScopeID, that policy MUST
include providing those Portlets whose PortletDescription indicate an interest
in the wsrp:navigationalScopeID parameter the same value for the duration
of the scope. The Portlet SHOULD
NOT return a value for this navigational parameter and the Consumer MUST
ignore any Portlet supplied value.

----------------------------------------------
end draft -------------------------------------------

Clearly this is modeled after the language
we had worked through for the event being replaced ...

I considered also defining the identifier
to be used for this parameter, but the risk of naming collision rises dramatically
since it of type string. Anyone see a problem with letting the identifier
be specific to the Portlet?

Rich

Subbu Allamaraju <subbu@bea.com>

09/14/2006 10:50 AM

To	Rich Thompson/Watson/IBM@IBMUS
cc	WSRP TC <wsrp@lists.oasis-open.org>, mary.mcrae@oasis-open.org
Subject	Re: [wsrp] Suggestion to change the newNavigationalContextScope event into a navigational parameter

Could you or Stefan point out the following

- the current sections/statements
- requested changes (including any conformance statements, structure 
changes)

Subbu

Rich Thompson wrote:
> 
> 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
> 
> 

>>Register now for BEA World 2006 --- See http://www.bea.com/beaworld<<
_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries
 and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted
 and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.