ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul R Brown <paulrbr...@gmail.com>
Subject Re: BPEL Object Model and Parser
Date Thu, 27 Apr 2006 02:57:43 GMT

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  

> 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:


Paul R Brown

View raw message