ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance Waterman" <lance.water...@gmail.com>
Subject Re: are we really gonna end up with 1 engine anyway?
Date Thu, 23 Feb 2006 17:24:16 GMT
Paul,

I have been looking through the bpel-parser and bom and want to make sure
I'm on right track. I got the source from here (
http://pxe.intalio.org/public/pxe-src-r812.zip ) and have been focusing on
the packages com.fx.pxe.sax.fsa.bpel_2_0 and com.fx.pxe.bom.api. I am
looking for parser/bom support for some of the new 2.0 constructs ( i.e.
<if>,<forEach>, etc ... ) and I don't see these objects ( i.e.
com.fx.pxe.sax.fsa.bpel_2_0.BpelIfState ). Am I looking in the right place
or perhaps I'm making a bad assumption as to the implementation?

Lance

On 2/21/06, Paul Brown <paulrbrown@gmail.com> wrote:
>
> Hi, Lance --
>
> > At this point, I think I used the term "parser" a bit too generically. I
> > should have used the term "translator".
>
> Then you'd want bpel-parser + bom. :)
>
> The bpel-parser module is a SAX-only, grammar-based approach to
> parsing both dialects of BPEL and mapping them to a normalized object
> model that contains the necessary information for both 1.1 and 2.0.
> The current tool chain within PXE is something like this:
>
> text -[xml parser]-> SAX -[bpel-parser]-> BOM -[bpel-compiler]-> O-model
>
> And the O-model is what's used to generate the "byte code" for the PXE
> PVM at runtime.  The bpel-compiler contains most of the static
> analysis logic and enforcement, while the parser is based on the BPEL
> grammar but not according to the schema, since XML Schema doesn't
> capture a good number of the semantics needed.  (Non-deterministic
> content model blah blah.)
>
> I'll go on record as stating that I don't think that having one engine
> makes sense as a goal, but I do think that it makes sense to have an
> emphasis, as a collective, on generating independently useful
> artifacts from each engine effort, e.g., parsing and static analysis.
>
> We can start with the notion of having a Crimson and a Xerces, which
> is appropriate if you think about how the two parsers were originally
> conceived (SUN/IBM, different implementation approaches) and donated
> to Apache.
>
> Cheers.
>
> -- Paul
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message