Attached my comments.
Subbu
Rich Thompson wrote:
>
> I like the idea of adding a table describing the different types of
> state. I think another describing the different coordination mechanisms
> would also be useful. I have made a start on two such appendices (I
> think an appendix is the right place as it is really commentary on a
> particular portion of the spec rather than definitional.
>
>
>
> Thoughts? comments?
>
> Rich
>
>
> *Michael Freedman <>*
>
> 12/15/05 04:23 PM
>
>
> To
> OASIS WSRP TC <>
> cc
>
> Subject
> Re: [wsrp] Navigation params comments
>
>
>
>
>
>
>
>
> Rich,
> Yes, we should clarify its use. I just finished a conversation with
> some folks in my development team where they completely missed needing
> to use navigational parameters as inputs to internal state. Rather they
> equated them more with the current navigational state concept which
> holds state. One of the developers suggested providing a table that
> includes all the mechanisms and lists such factors as whether it
> represents managed state or not, whether its for interportlet comm or
> not, etc.
> -Mike-
>
> Rich Thompson wrote:
>
> By the way, sections numbers are always handy ... your page 29 resolves
> to section 5.1.17 on page 30 for me.
>
> My comments:
>
> a. The TC decided that "it is always a Consumer choice to supply them
> /(navigationParameters)/ on a particular invocation". The direct fallout
> of this is that the navigationParameterDescription is not allowed to
> require supplying if a particular item. This results in a model where
> the Consumer only supplies new values when they occur and the Portlet.
> Perhaps what is missing is a more concrete description (both here and in
> 6.1.11) that navigationParameters are simply an input which the Portlet
> SHOULD then store in its navigational state.
>
> b. This sentence is providing guidance about how navigationParameters
> are shared between portlets, but is explicitly noting that the guidance
> likely doesn't apply when two portlets customized from the same POP
> within the sharing scope (likely the page).
>
> Rich
>
> *Subbu Allamaraju **_<>_* <mailto:>
>
> 12/14/05 03:06 PM
>
>
> To
> OASIS WSRP TC _<>_
> <mailto:>
> cc
>
> Subject
> [wsrp] Navigation params comments
>
>
>
>
>
>
>
>
>
>
> Two questions/comments on the navigationParameterDescriptions (page 29
> of draft 12):
>
> a. There is a statement that says that
>
> "As such, regardless of the values in the PropertyDescription‘s
> capabilities field, navigationParameters are always modifiable and
> optional."
>
> Does not this weaken the notion of wsrp:required capability?
>
> b. The intent of the next sentence is not clear to me.
>
> "While Consumer policy governs what navigation parameters are supplied
> to each invocation of a Portlet, Consumers SHOULD supply the same value
> to Portlets which are related to distinct Producer offered portlet
> handles and provide a navigationParameterDescription referencing the
> same QName for the parameter’s name."
>
> I think what we want to say is that the consumer should try to supply
> the same value to any portlet with a matching name as specified in
> navigationParameterDescription. How about changing this text to the
> following?
>
> "While Consumer policy governs what navigation parameters are supplied
> to each invocation of a Portlet, Consumers SHOULD supply the same value
> to any portlet with the same QName for the parameter's name as specified
> in the portlet's navigationParameterDescription."
>
> Subbu
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. You may a link to this group and all your TCs in OASIS
> at:_
> __https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php_
>
>
> --------------------------------------------------------------------- To
> unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. You may a link to this group and all your TCs in
> OASIS at:
> _https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php_
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. You may a link to this group and all your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php