Let's standardize for SMTP and JDBC to start with

Removed EP551_WAIVER_APPROVED

This issue has implications with respect to each of the Binding Component or
different protocols under consideration. Each of the protocol has its own
protocol Metadata or way of representing the Metadata. For eg. SMTP has <From,
TO, CC, BCC, Subject, Body> etc. where as JMS has <QueueName, MachineName, JNDI
Name> etc. 

We have the following alternatives:

1. having wizard for each of the protocol for capturing the metadata and
generating the .xsd file at the end of the wizard like in case of JDBC.
2. having the fixed .xsd stored somewhere at a fixed location for the protocol.
like in case of HL7.

Both the approaches have their own pros and cons.

1. Wizard will be user friendly but lot of protocols are simple like in case of
SMTP just requiring few fields to be filled in. The user might not feel going
this route.
2. Having static .xsd file might be restrictive and user might not know the
location or might not have access to the net where from he needs to download the
.xsd for that protocol. 

Though during runtime we can capture this as message metadada and handle it with
a MessageMetadataHandler this has issues with respect to capturing the metadata
uniformly or with a consistent interface. Lets examine the issues those are
involved in solving the issue and see whether going for this adds any value or
should we leave this alone

1. Difference of metadata at protocol level (Explained above).
2. Inconsistent Interfaces across components for creation of the Metadata
3. Lot of components are already implemented and this currently involves
refactoring to the existing components both at design time and runtime. Bringing
them for a consensus might be an issue.
4. Last and most importantly lot of organizations have fixed set of .xsds which
model their business needs well and might be averse to have the fixed set of
.xsds imposed by us. They might feel that we are more restrictive. 

I would like to listen to any feed back. We need not have this currently as P2
so I am downgrading this to p5 and marking this as wont fix.

Narayanaa,

Ok I understand your reasoning but a key enhancement that should be possible
without affecting existing implementation is to extend the BC to allow the use
of XPath. If we take for example the SMTP BC when specifying the input parts;
subject, message, etc; I need to define them as multiple separate input parts
whereas what I may have is my company standard xsd structure for email and hence
I want to pass in a single input part based on this xsd and then reference the
subject element using XPath.

This would also resolve some of the questions you raised,i.e.;

1. We could have a single creation Wizard.
2. Do not have a static xsd.
3. This could be additional functionality so people using the exist, SMTP, BC
would continue working the same way but anyone wanting to us a structure can use
the new method.

You should still able to do that having your .xsd imported into the SMTP WSDL
and using the same in the input section. You should able to have the xpath
xpression and able to map element to element from the BPEL mapper itself if the
xsd structure are equal. If that does not happen currently that should be an
enhancement on the BPEL mapper.