RE: [wsrp-interop] Original Emails on event QNames

[Richard Jacob <richard.jacob@de.ibm.com>]

See inline <rj></rj>

@your first question
a) Portlet A published Event A aliased to B
b) And Portlet B generates and subscribes to Event B
During the meeting, the following thoughts were offered:

a) Event A should be sent to portlet B as Event A NOT modified
<rj>that's against the specs,
portlet B declares what it wants to receive and must get that.</rj>

b) Event A is renamed to event B but the payload is NOT modified (most
votes)
<rj>that's not what we discussed,
the discussion was tied to the root element's name and if that needs to
be the events name's qname.
That would be also against the spec
iff portlet B declared a type definition in the portletDescription.
Same is true for the JSR spec.</rj>

c) Event A is renamed to event B and the root element is renamed to event
B
<rj>see answer to  b). I
think it should not to be necessary to rename the root element name. Since
the type is known here, it can be deserialized.
Note that when we go one step furthet
and talk about even different declared types, then per spec it woud be
the consumers responsibility to do a payload transformation.
This is/maybe one of the reasone, Kevin
is asking for non-declared simple types which could be exchanged reliably
without complex payload transformation.
I'm not aware of any implementation
in the world which could do payload transformations on the fly... can you?
So I would not step into that at this
discussion.</rj>

d) What does the schema for an event look like with aliases? Is the element
under the payload defined in the schema or just its type?
<rj>the spec references the payload
type in the xsd, the root element can be chosen arbitrary. The WSRP spec
"proposes" to use the event Qname as the root element name.</rj>

Mit freundlichen Grüßen / Kind regards
Richard Jacob
Team Lead Portal Standards & WCM development WSRP Standardization Lead
IBM Software Group, WPLC
WSS Websphere Portal Foundation Development 1
Phone:	+49-7031-16-3469	IBM Deutschland Research & Development
E-Mail:	richard.jacob@de.ibm.com	Schoenaicher Str. 220
		71032 Boeblingen
		Germany
IBM Deutschland Research & Development GmbH / Vorsitzender des Aufsichtsrats: Martin Jetter Geschäftsführung: Erich Baier Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294

 

From:	"Nader Oteifa" <nader2@netunitysoftware.com>
To:	<wsrp-interop@lists.oasis-open.org>
Date:	10/26/2009 08:24 PM
Subject:	RE: [wsrp-interop] Original Emails on event QNames

---

Kevin brought up a very interesting point regarding
event aliases during our
WSRP meeting.  Take the following use case:

a) Portlet A published Event A aliased to B
b) And Portlet B generates and subscribes to Event B
 
During the meeting, the following thoughts were offered:

a) Event A should be sent to portlet B as Event A NOT modified
b) Event A is renamed to event B but the payload is NOT modified (most
votes)
c) Event A is renamed to event B and the root element is renamed to event
B
d) What does the schema for an event look like with aliases? Is the element
under the payload defined in the schema or just its type?

If you read the spec now regarding aliases:

aliases: An array of the QNames of events known to be semantically
equivalent to this event. While this can provide a hint to the Consumer
concerning potential items that could be correlated with this event, it
remains the Consumer's responsibility do any transformations required to
produce the described event.

To me, this sounds like if portlet A generates Event A, the consumer will
transform the Event A and its payload to Event B and send it to portlet
B.
Therefore, portlet B only see Event B and the payload it expects.  This
tell
me that aliases are just a "hint" as to what the payload could
be
transformed to but the consumer is responsible for the mapping and it's
purely optional; portlet B might never get an event if the consumer does
not
care to map these two events even if aliased.  This is just another
interpretation of how aliases affect events based on reading the description
of aliases in the specification. 

Given the varied interpretation on implementations, it appears there is
quite a bit of confusion on how aliases work.  Therefore, I think
we need to
agree on the answers to some basic questions first:

a) What's the problem aliases are trying to solve?  What are the use
cases
for aliases?  
b) Are aliases a hint as to what other events a given event can be
transformed into?  
c) Is it strictly a consumer transformation? A predetermined transformation
(e.g. change the name of event, change the root payload element name, etc.)?

d) Is it optional or required to send the event if there is a match on
aliases?
e) Who's aliases are used?  The generating portlet, the handling portlet,
both?  Note the spec. indicates both generated and handled events
need to be
described which brings up other inconsistency problems.
f) Can an event map to more than one target event via aliases?
g) What effect do aliases have on opaque payloads and wildcard subscribed
events if any?

Can we discuss these questions in one of our next scheduled meetings?

Nader

-----Original Message-----
From: Nathan Lipke [mailto:nathan.lipke@oracle.com]
Sent: Thursday, October 22, 2009 11:38 AM
To: wsrp-interop@lists.oasis-open.org
Subject: [wsrp-interop] Original Emails on event QNames

http://www.oasis-open.org/apps/org/workgroup/wsrp/wsrp-interop/email/archive
s/200710/msg00002.html

Use the "Thread Next" link to see the follow-ups.

Nate

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to 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.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php