Hi all, So, given these additional elements, what do you think about my initial proposal (take bpel object model and parser from pxe)? I think it's already in a pretty good shape, which is the whole point of code donations, and can easily be improved to support extensions or other missing parts.
Cheers, Matthieu. On 4/27/06, Paul R Brown <[EMAIL PROTECTED]> wrote: > > Hi, Sanjiva -- > > >> 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. > > Um why is validation a mandatory thing? If you want to validate before > > reading then you can do it using various forms- IMO forcing validation > > upon reading is not necessary. > > Validation is a desirable thing, at least IMHO. Is there a QName > where there is supposed to be a QName? Is the content of an > expression in the right place? Is the namespace of the root element > correct? Ultimately, validating against the schema and building the > toolchain to only accept valid (and semantically correct) BPEL is a > contract with the user -- we'll do what you want/expect if you supply > correct input. (Semantically-correct BPEL is a subset of schema- > valid BPEL.) > > I have previously done the work of translating the XML Schemas for > versions of BPEL into RELAX NG, and there is a good amount of > meaningful information (e.g., exclusion of the presence of one > attribute based on the presence of another) that the XML Schemas do > not include. All of this is meaningful for BPEL -- If both > attributes are present, which do you want the engine to use? The > schemas or grammars are a kind of program that suits the problem > domain and are generally agreed to meet the need. > > Of course, it would be nice if people would just define real grammars > if they're going to make programming languages, but I digress... :) > > > The other aspect of the object model design must of course be that one > > can create instances of the model in memory and run with just that > > instead of having a .bpel XML file around at all. > > The BOM is intended to be a developer-friendly (the things have the > same names in the OM as they do in the BPEL) object model for BPEL -- > add activities to a scope, etc. It was ideally conceived to be both > the target of the parser component and a potential model for > something like a graphical designer or MDA toolchain that had nothing > to do with XML at all. > > -- > Paul R Brown > [EMAIL PROTECTED] > http://mult.ifario.us/ > > >
