I have checked in a simple m2 project so that one can take a look at the
classes generated by jaxb2 from the bpel xsd schema.
This is available at:
http://svn.apache.org/repos/asf/incubator/ode/scratch/ode/bpel-jaxb/
Just run 'mvn install' and find the generated code in 'target/jaxb-source'.
This is indeed close to api and has several benefits:
* nothing to maintain -- and thus bug free, unless jaxb2 is bugged ;)
* automatically handle extensions (by jaxb2 framework)
* handle several xml input types: StaX, DOM, SAX or any JAXP Source
* able to marshal the data objects back to xml
However, there are also drawbacks:
* no tight control over the api (though we should be able to really
override the jaxb generation through xml configuration files)
* do not use interfaces (jaxb2 should be able to generate interfaces
for complex types, but i haven't succeeded)
We could easily plug in a semantic validator in addition to the schema
validation provided by the xml parser used.
Cheers,
Guillaume Nodet
Paul R Brown wrote:
Hi, Guillaume --
I'd like this api to capture the full xml infoset if possible.
What I mean is that there are places in the bpel schema where
extensions are permitted (attributes and/or elements), and I think
it could be usefull to keep then (instead of just ignoring them).
So I think both modules could be enhanced ...
I completely agree about the extensions, and that was on the list of
to-do's at the time. It should be possible to do at runtime by
enhancing the abstract syntax structure that the bpel-parser uses to
do its work.
Ideally, the way that this would be done would be to add to the BOM
to allow it to capture extension attributes and elements. There
would also be some requirements around navigation of the tree so that
extension processors can move around in the tree.
I'm willing to sketch out and/or implement the changes that would be
needed.
Alternatively, this could be easily handled by an xml / object
mapping tool like jaxb2 (or xmlbeans) ...
Jaxb2 is very simple, generates nice pojos (this is not the case
with xmlbeans) and afaik, both handles unspecified extensions to
schemas...
Or even a stax based parsing would be great (sax is such a
nightmare compared to pull parsing..).
JAXB v2 wasn't available (with a suitable license) when we were
originally working on PXE, so that was ruled out.
StAX parsing won't permit schema validation, so that's a no-go
there. And schema validation isn't truly enough, as there are valid
but illegal BPEL processes.
I wrote a blog entry about the thought process that went into it:
http://mult.ifario.us/articles/2006/02/05/populating-a-java-object-
model-from-xml
--
Paul R Brown
[EMAIL PROTECTED]
http://mult.ifario.us/
