I was looking over the parser/BOM ( PXE donated ) and have a couple of questions.
1) It appears that the BOM normalizes BPEL 1.1 vs 2.0 syntax. Is this so language changes have a trickle down affect on the "compiler" ( i.e. the O-Model )? 2) Note - the BPE parsed and did semantic validation directly into an "object model". In looking at the PXE parser it looks like all/most semantic checking is done here as well. So again, is the main purpose of the BOM to reduce language change impact on the compiler? I think Paul may have mentioned that the intent of the BOM was to be used by developers ( specifically tooling developers ). My guess is that many tools will probably generate and use their platform modeling infrastructure ( i.e. Eclipse tooling will generate an EMF model from the BPEL schema ). 3) Not sure, but it looks like the parser supports mixing BPEL1.1 elements and BPEL2.0 elements within the same process definition? If this is true - what is the use case for this? 4) ( Guillaume ) - you mentioned that you don't care for SAX based parsing ( i.e. over StAX ) however, for this particular use case I don't understand how a pull parser would benefit? Are you thinking from a coding style standpoint? Thanks, Lance On 5/2/06, Matthieu Riou <[EMAIL PROTECTED]> wrote:
Another important thing that was listed in Paul's blog is the ability to know on which line of the original document the error was detected. It's a useful feature from a user prospective. Cheers, Matthieu. On 5/2/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote: > I have checked in a simple m2 project so that one can take a look at the > classes generated by jaxb2 from the bpel xsd schema. > This is available at: > http://svn.apache.org/repos/asf/incubator/ode/scratch/ode/bpel-jaxb/ > Just run 'mvn install' and find the generated code in 'target/jaxb-source'. > > This is indeed close to api and has several benefits: > * nothing to maintain -- and thus bug free, unless jaxb2 is bugged ;) > * automatically handle extensions (by jaxb2 framework) > * handle several xml input types: StaX, DOM, SAX or any JAXP Source > * able to marshal the data objects back to xml > However, there are also drawbacks: > * no tight control over the api (though we should be able to really > override the jaxb generation through xml configuration files) > * do not use interfaces (jaxb2 should be able to generate interfaces > for complex types, but i haven't succeeded) > > We could easily plug in a semantic validator in addition to the schema > validation provided by the xml parser used. > > Cheers, > Guillaume Nodet > > Paul R Brown wrote: > > > > > Hi, Guillaume -- > > > >> I'd like this api to capture the full xml infoset if possible. > >> What I mean is that there are places in the bpel schema where > >> extensions are permitted (attributes and/or elements), and I think > >> it could be usefull to keep then (instead of just ignoring them). > >> So I think both modules could be enhanced ... > > > > > > I completely agree about the extensions, and that was on the list of > > to-do's at the time. It should be possible to do at runtime by > > enhancing the abstract syntax structure that the bpel-parser uses to > > do its work. > > > > Ideally, the way that this would be done would be to add to the BOM > > to allow it to capture extension attributes and elements. There > > would also be some requirements around navigation of the tree so that > > extension processors can move around in the tree. > > > > I'm willing to sketch out and/or implement the changes that would be > > needed. > > > >> Alternatively, this could be easily handled by an xml / object > >> mapping tool like jaxb2 (or xmlbeans) ... > >> Jaxb2 is very simple, generates nice pojos (this is not the case > >> with xmlbeans) and afaik, both handles unspecified extensions to > >> schemas... > >> Or even a stax based parsing would be great (sax is such a > >> nightmare compared to pull parsing..). > > > > > > JAXB v2 wasn't available (with a suitable license) when we were > > originally working on PXE, so that was ruled out. > > > > 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. > > > > I wrote a blog entry about the thought process that went into it: > > > > http://mult.ifario.us/articles/2006/02/05/populating-a-java-object- > > model-from-xml > > > > -- > > Paul R Brown > > [EMAIL PROTECTED] > > http://mult.ifario.us/ > > > > > > > > >
