OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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



Also, it is a shared state model. Each portlet is expressing the identifier by which it will know the item and the QName(s) which identify the semantics of the item.

Rich



Subbu Allamaraju <subbu@bea.com>

09/19/2006 09:41 AM

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 was completely off the track. Having re-read the spec, the identifier
is what should get sent at runtime. Let's clarify that in a primer or
some such place.

Subbu

Stefan Hepper wrote:
> 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.
>>
>
>

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]