Please investigate

[Michael Freedman <michael.freedman@oracle.com>]

I today's concall we discussed the concept of supporting event, 
property, and parameter aliases.  Though we liked the idea and thought 
it should be included in the standard a question was raise on how easy a 
consumer will be able to support this given potential type conversion.  
We decided the TCs consumer implementors for their feedback based on 
their consumer implemetnations.  If you are a consumer implementor can 
you investigate whether you will have significant issues/problems with 
supporting aliasing? 

The basic problem we discussed is that when aliases are introduced it 
likely means that each producer has a distinct type for the construct.  
Though we expect in such situations that the types are compatible [of 
the same form/structure], the typing will be different.  [I.e. think 
about this from an object perspective -- I may have an object of type 
Foo that represents a customerId and and object of type Bar that 
represents the same customerId -- the types are compatible but distinct 
-- you can't cast from one to the other, etc.]  With aliasing the 
consumer will be expected to recognize that Foo is a synonym for bar and 
pass the value associated with Foo to the portlet expecting it as type 
Foo and the portlet expecting it as type Bar.  The consumer will be 
responsible for sending this as the appropriate/expected type.  The 
question we are asking folks to investigate is whether this is a 
reasonable expectation/requirement in your consumer environments. 

Please investigate and let us know no later then the Dec 15th concall 
because without eveidence to the contrary we are going to assume this 
isn't a burden and add aliasing to the spec.

       -Mike-