Re: [wsrp] sematics of overlapping QNames for navParams?

[Stefan Hepper <sthepper@hursley.ibm.com>]

Thanks Rich, that clarifies a lot.

Can we add as clarification in 6.1.12 that the name in the NameString 
must reference to the identifier?

About my second point:
So basically you are saying that a wiring happens between different 
identifiers and not that reference to a common shared data.
So it is more like the event model than a data sharing model.
Can we also clarify this, as I think also other people would think that 
this is meant to be a data sharing model, like I did?

Stefan


Rich Thompson wrote:
> 
> Inserted inline with <rt> ...
> 
> Rich
> 
> 
> *Subbu Allamaraju <subbu@bea.com>*
> 
> 09/18/2006 02:26 PM
> 
> 	
> To
> 	Stefan Hepper <sthepper@hursley.ibm.com>
> cc
> 	WSRP TC <wsrp@lists.oasis-open.org>
> Subject
> 	Re: [wsrp] sematics of overlapping QNames for navParams?
> 
> 
> 	
> 
> 
> 
> 
> 
>  > I assume it is too late to restrict this to one QName instead of a QName
> 
> That's what the errata is for :)
> 
> <rt>The Qnames are definitions of the semantics of items which can be 
> mapped into this navParam. The navParam is defined by the identifier 
> field.</rt>
> 
>  > Here a few scenarios:
>  >
>  > portlet 1:
>  > nav param aaa:p1, bbb:blub <rt>identifier = "1"</rt>
>  > nav param aaa:p2 <rt>identifier = "2"</rt>
>  >
>  > portlet 2:
>  > nav param bbb:blub, ccc:bla <rt>identifier = "3"</rt>
>  >
>  > portlet 3:
>  > nav param ccc:bla, aaa:p2 <rt>identifier = "4"</rt>
>  >
>  >
>  > questions:
>  >
>  > 1. what if portlet 1 creates an url setting bbb:bulb to "123"? Will it
>  > get the param under the name aaa:p1 or under bbb:blub? I didn't find
>  > anything in the spec about this. I expected to find that the portlet
>  > must only use the first entry in the QName list.
> 
> Yes. My interpretation is that the portlet should be ready to receive
> the value against any of the names it declared.
> 
> <rt>/The portlet receives the value against the identifier it has 
> declared./</rt>
> 
>  > 2. What is the happens when portlet 1 sets
>  > aaa:p1 = "111" ?
> 
> <rt>Translate this to setting identifier 1 to a value of "111".</rt>
> 
>  > Can portlet 2 receive this as new value bbb:blub? (I assume yes based on
>  > the current spec)
> 
> No. My interpretation is the the recipient has to declare the aliases.
> Since it did not declare "aaa:p1", it will not receive it.
> 
> <rt>Portlet 2 would recieve identifier 3 with the value "111".</rt>
> 
>  > Can portlet 3 receive it as new value for ccc:bla? (unclear to me from
>  > the current spec, it states: "SHOULD supply the same value to Portlets
>  > which provide a navigationalParameterDescription  referencing the same
>  > QName in the names array", and ccc:bla is not on the QName list of
>  > portlet 1)
> 
> No, per the same argument.
> 
> <rt>Portlet 3 would recieve identifier 4 with the value "111".</rt>
> 
>  >
>  > Can portlet 1 receive it as new value for aaa:p2?
> 
> No
> 
> <rt>Only if Portlet 3 returns identifier 4 with the value "111".</rt>
> 
>  > 3. What happens if portlet 2 sets
>  > bbb:blub = "222" ?
>  >
>  > Can portlet 1 receive this as new value for aaa:p1 and portlet 3 as new
>  > values for ccc:bla? I assume yes.
> 
> Portlet 1 will receive this as new value for bbb:blub and portlet 3 will
> not receive it.
> 
> The reason we ended up having multiple names was to account for alias
> names. Alias are meant to help the consumer decide whether to send the
> param (or dispatch an event) to a given portlet. If one of the names
> matches, it will dispatch it, otherwise not.
> 
> There is no name translation in this process. That is, the recipient
> will receive it under the same name as was sent/set by the sender.
> 
> <rt>We made a distinction between identifying a navParam and the QNames 
> to which it should be mapped. The runtime messages use the NamedString 
> type, but it appears we were not explicit that the identifier field is 
> what would appear in the name field of this type and that the QNames are 
> just for the purpose of mapping navParams across portlets.</rt>
> 
> 
> Subbu
>  >>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.
>