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: [no subject]

This raises the questions of policy and relatability (items 2 & 3
and any standardization for something along the lines of #3 above.

How difficult will it be to have real "context passing" (ex: transaction
keys, or any other form of "interesting" data) to "interested" portlets?

NOTE #1: For the consumer to supply publicParameters with data received
from events, the consumer must understand the event.

NOTE #2: Is there a need for a common catalog of published events? It
that application vendors may create their own event catalogs (possibly
without regard) to existing events. From the perspective of delivering
value to a consumer, one of two things must happen. Either the consumer
takes responsibility for a mapping and translation component and supply
result as publicParameters (lots of work for the consumer). Or each
must understand every other portlets events that may possibly exist
(including future ones). In which case the consumer may be able to
portlets, but gain no "connectivity" benefit.


ricky_frost@peoplesoft.com wrote:

I apologize if these are covered elsewhere (or discussed previously),
but after looking at draft04 I couldn't readily find the answers to
these questions:

1. Could we clearly describe at least one case for each where one might
use portletProperties and publicParameters?
I did find that properties were guaranteed to be persistent, while
publicParameters were guaranteed not to be.
Also, publicParameters seem to be some kind of publicly (i.e. consumer)
suppliable navigational state.
I suspect that someone might think that they were similar (and
as I initially did :-)

Going forward with the idea that publicParameters are a kind of
navigational state, I had 2 other questions:

2. Might there be name recognition or mapping issues of publicParameters
between consumer and producer? Do we need to introduce similar naming as
in events?  (i.e. hierarchical)

3. Might there be privacy (or at least policy) issues of supplying them
to a producer (given that the data may be sourced by another producer)?
Ex: is it appropriate to allow the "ACCT_NO" property from producer,
"schwab.com", to populate the similarly named publicParameter on
"nefarious.com"? I think not. I realize that there might have to be some
kind of policy enforcement on the consumer, but might we do something to
assist in that effort? Or is this out of the scope of the spec?

To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to

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