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/
