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/ > > > >
