wsrp-coord message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp-coord] Comments on Events Semantics Doc
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp-coord@lists.oasis-open.org
- Date: Tue, 14 Sep 2004 17:14:02 -0400
My take:
1. I would like to turn the open questions
into an issues list that we systematically work our way through. I think
this will need people to step up to fleshing out the pros and cons of the
various issues so that a decision can be reached. This will likely be a
list that grows a bit as people now see the changes we have discussed in
the broader context of the spec.
2. The discussion about '/' or '.' was
left open the last time it was discussed.
3. I think the reason we had set the
handled events as QName[] was that portlets could easily be handled events
defined in other namespaces. I see the issue you raise ... if we make it
an EventDescription[], it would mean that the schemas defining such interesting
events would need to be reachable so that they could be dealt with via
an include.
4. The semantics are that an interaction
is an event that has been serialized to markup. I can't remember an eventing
system where single generations of events ever dominated, though the number
of generations is often small.
5. This question deals with how a Consumer
advertises its capabilities. The axis discussed included doing event distribution,
only distributing events whose payloads are of type string and full support
for distributing generated events.
Rich
"Goldstein, Scott"
<Scott.Goldstein@vignette.com>
09/14/2004 02:55 PM
|
To
| <wsrp-coord@lists.oasis-open.org>
|
cc
|
|
Subject
| [wsrp-coord] Comments on
Events Semantics Doc |
|
Rich mentioned in the last conference call
that now was a good time to bring up questions/issues with the current
eventing semantics doc, given that it’s being put into the 2.0 spec. Here
are our comments:
1. There
are still a significant number of open questions listed in the doc which
appear not to have made it into the WSRP 2.0 spec draft. Will we
continue working with the semantics doc and then push the changes into
the WSRP 2.0 spec? Or, does it make sense to add the open questions
to the WSRP 2.0? It doesn’t seem to make sense at this point to
apply changes to both docs.
2. Minor
- In the suggested hierarchy of event names, we had discussed changing
the “/”’s to “.”’s. I see that the open question about confusion
with Xpath is still there. I don’t recall, however, anyone having
a problem changing to “.”’s. Any thoughts on this?
3. In
the PortletDescription, why is the type of the handleEvents element a QName[]
instead of a an EventDescription[]? Imagine the following scenario:
I consume a portlet which states that it can receive events of name,
“ns1:zipCodeEvent”. Imagine that I consume another portlet which
states that it published an event with name, “n55:myZipCodeEvent”, data
type, “xsd:string”, and description, “The current zip code selected.”
As a portal administrator, I may want to map the published, “n55:myZipCodeEvent”
to be received by the first portlet as, “ns1:zipCodeEvent”. Unfortunately,
without a data type and description, I don’t know what the first portlet
is expected. However, if handleEvents was an EventDescription[],
all of this information would be provided, facilitating this mapping.
4. Can
someone provide a specific use case around event chaining (returning events
from a handleEvents() calls)? I’m having trouble seeing the need
for this. The only possibility that I can some up with, is for sending
an ACK, which might be useful based on the way we’re defining the Consumer
as an intelligent entity capable of making the decision not to send events.
Is this the case that has come up or are there others? Also,
would the sending of ACKs be our best practice suggestion of verifying
event propagation?
5. Open
Question #3 – What is the difference between a simpleEvent and a complexEvent?
Thanks.
Scott
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]