+1 to merge the tests and get both engines to pass them (when they implement the version of the spec)
thanks, dims On 2/22/06, Lance Waterman <[EMAIL PROTECTED]> wrote: > Dims/Paul, > > Thanks, I have the PXE source and will take a look to see if the bpel-parser > + bom would make sense to reuse. > > I would like to try and steer this discussion back to my original question > on defining a common set of BPEL acceptance tests. Do you think this sounds > like a reasonable thing to achieve? I noticed there are BPEL documents > located at ( pxe\bpel-scripts\src1.1\good and pxe\bpel-scripts\src\2.0\good > ). Do you consider these the PXE acceptance tests? The Sybase donation has > BPEL test documents located at ( bpe\bpelTests ). Does it make sense to > start by merging these two groups of tests? > > 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 > > > > -- Davanum Srinivas : http://wso2.com/blogs/
