ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthieu Riou" <matthieu.r...@gmail.com>
Subject Re: BPEL Object Model and Parser
Date Thu, 27 Apr 2006 14:57:07 GMT
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.



On 4/27/06, Paul R Brown <paulrbrown@gmail.com> 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
> paulrbrown@gmail.com
> http://mult.ifario.us/

View raw message