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?
- From: Rich Thompson <richt2@us.ibm.com>
- To: WSRP TC <wsrp@lists.oasis-open.org>
- Date: Tue, 19 Sep 2006 11:47:18 -0400
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]