Sounds good, I will start a new thread around deployment. I also volunteer to put together a deployment API proposal ( similar in scope to Maciej's runtime API ).
Lance On 5/1/06, Matthieu Riou <[EMAIL PROTECTED]> wrote:
Lance, Sorry for not replying to your previous e-mail, I've been a bit busy. I'll import the bom and the parser this week. Meanwhile it's probably a good idea to start a discussion on another about ODE's deployment units. Cheers, Matthieu. On 5/1/06, Lance Waterman <[EMAIL PROTECTED]> wrote: > Matthieu, > > This is fine with me. > > Lance > > > On 4/27/06, Matthieu Riou < [EMAIL PROTECTED]> wrote: > > 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/ > > > > > > > > > > > > >
