Issue #6 Discussion - Wouldn't EventDescription[] be a better type for handledEvents?

In the current draft of the 2.0 specification, the portlet
declares, through the PortletDescription, which events it can receive. 
This information is currently passed as an array of QName elements representing
the array of names of the events that it understands.  The problem with
this choice of data type, is that it doesn’t handle the following use
case very well:

 

Suppose that there are three portlets on separate producers
that have the following event characteristics:

 
Portlet A – Sends an
     event with name, “ns1:CurrentZipCode”, with the event data
     type, xsd:string.

 
Portlet B1 – Receives an
     event with name, “ns2:MyZipCode”, with the event data type,
     xsd:string.

 
Portlet B2 – Recieves an
     event with name, “ns3:TheZip”, with event data type,
     ns3:ZipType

 

The Consumer provides the admin a screen to map sent events
to received events.  The admin maps the sent event from Portlet A to be
received by both portlet B1 and B2.  He/She does this, because all that a
portlet provides when stating which events it receives is the name of the
event.  Because the names look similar, he/she assumes it’s
okay.  When the event is sent, however, an error occurs because
there’s a data type mismatch between what Portlet A sends and what
Portlet B1 receives.  

 

Another aspect of this problem, is that two events may have
the same datatype and similar names, but may have different purposes.  In
this case, it would be useful to have a description in the handleEvents
structure to provide a better idea of what the portlet is expecting.  

 

The proposal is to change the handledEvents field to an
array of EventDescription’s:

 

Advnatages:

 
Facilitates event mapping on
     the consumer side

 

Disadvantages:

 
This would introduce an
     additonal QName within the handleEvents element for the event payload
     datatype.  If it’s a standard xsd type, this won’t be a
     concern.  However, if it’s not a standard xsd type, it will
     require the producer to include the schema for the data type.  

 
The added data type information
     causes wildcards to be a bit awkward.  Some possible solutions would be:

 
  
Accepting it

  
Making the Data Type field of
      EventDescription optional

 

 

In my opinion, I think the disadvantages are worth the enhanced
consumer application functionality.

 

Any other opinions/comments?

 

Scott