Currently we got the following situation with respect to the JBI xml schema:
- There is a schema definition in petals-jbi-descriptor that follows the official JBI specification
- associated to it are JAXB generated classes and a JAXB parser to get a Java view of a jbi xml file.
- There is an extension in the same project
- the schema describe only the supplementary elements in a different namespace without saying where they are (it does not actually extends the jbi schema)
- there is a JAXB parser that is applied in an ad-hoc way to the anyOrAny element of the service element.
- There is the CDK jbidescriptor that completely redefines the JBI schema with its added elements
- there are associated JAXB Java classes and the parser
- For some components, there is extension to the CDK schema defined with xsd
- but they are not actually used as real schema extension of the CDK jbi (not used for validation, not used for parsing with the CDK parser)
- sometimes there are ad-hoc jaxb parser for them (for example in the SE BPMN2)
There is thus the following problem:
- some classes are duplicated and potentially different between the original JBI and the CDK jbi
- there is ad-hoc handling of the original extension but manipulable using Java classes
- there is ad-hoc low-level handling of the component-specific schema elements without any generalised mechanism to validate and parse them.
Currently, things work because there is multiple "any" elements everywhere (in services, consumes and provides I think... maybe in other places) we have the need to add component-specific things in an ad-hoc way...
In the same way as with the issue EASYWSDL-13, we should try to find a way to:
- reuse generated classes, but in this case the problem is mainly that we want to extend schemas.
- provide, from a component development point of view, a JAXB parser that takes the extension as an xsd and as generated classes, and that parse the extended xml files seamlessly.
The first one is going to be hard, the second one should be easier.