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 <[EMAIL PROTECTED]> 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 >
