I noticed that the schema used for the BPEL component references an older version of the SCA schema. Is it possible for us to modify the component code to use the BPEL definition provided by the sca-1.1-cd06 version of the SCA specification (i.e. sca-implementation-bpel-1.1-cd03.xsd instead of bpel-v1.xsd)?

The only change is the namespace for the implementation.bpel element. (The element definition is essentially the same.)

Did you try that? I wonder the current org.switchyard.config.model.Descriptor may only support just one marshaller for each one namespace, so in order to use other Schemas in SCA namespace, we may need to add marshaller logic into V1CompositeMarshaller in the core repo, or change the namespace and isolate from SCA default.

Assuming I understand the problem correctly, the quickest and cleanest way to solve this might be to simply acknowledge that multiple marshallers can be registered for a given namespace. Not sure how nicely fits with the current config API though.

David and I were actually chatting about the config API the other day. He put a lot of work into it back in the day and it's pretty much just plugged along without major mods for the better part of a year. In that year, we developed a better understanding of what our runtime and components would need from a config standpoint. In fact, I think we are still learning on that front. I sense that there will be one large (and final) refactoring there, and I don't believe we are ready for that yet. My preference would be to sit down with David and others and discuss all the changes at once instead of just updating as we go. So my feeling here would be to go with the least complex solution possible. If that's keeping a distinct namespace for now, let's just do that. If it's trivial to allow multiple handlers per namespace, then we can do that instead and use the standard SCA namespace. IMHO, what we should *not* do is drop 2-3 weeks on this right now when there are so many other important things to get done for 0.5.

This just occurred to me, but yet another option is that all of the standard SCA config support is added inside the config project. Or maybe we split all the SCA config into a distinct module. In any case, the standard SCA stuff would all go there, including things like BPEL. This is all standard stuff and not tied up with component code at all. Now, if a component has an extension to the SCA types that it wants to register, then that goes in the component project module with a distinct namespace.

Now that I think about it, I think this is better than the other two ideas I discussed above.

I agree that it would be best for us to get all our config requests/requirements put together instead of messing around as we go.

I would need to go back and research the possibilities/impact/estimate on the multiple namespaces front. It indeed has been plugging right along on it's own now for quite some time, so I'm a bit dusty on what I wrote - LOL. And as Keith said, we already have enough to do for 0.5.

Purely a Maven and modularity thing. At present, the core config has model classes for SCA elements (composite, component, etc.). We're talking about moving that to a distinct SCA config module in the project structure.