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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-coord message

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


Subject: 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]