[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 166 - Proposal To Vote
Hi Bernard: > an assign-specifying appendix sounds usefull to me. Major Point: Thanks. I believe a combination of a formalism (as simple as pre-conditions, post-conditions) and and getting the original author of section 14.3 to state their intent, would have put section 166 to rest a long time ago. That said, too much of BPEL is English narrative that is easy to misinterpret. Features like better illustrations and pseudo-code would better explain things. I also suspect it would shrink the size of the specification. > are some points, which are not really addressed. For > example is the assign schema aware? If I have a "a (b,c)" > complex type and assign > > <from>C</from><to query="/a/c" /> > <from>B</from><to query="/a/b" /> Minor Point One: I would suspect that assign is schema aware because variables and messages have type (and type is a XSD schema/WSDL definition). Minor Point Two. According to section 9.3, only partnerlinks, variables, and variable properties can the target of a <to>. Or in other words, a lValue. I suspect a parser would (or ought) to identify the query as an expression. I feel section 9.3 is somewhat arbitary. My feelings are any mutable infoset (variables, messages) should be a lValue candidate. Likewise XPath should be used to navigate any BPEL object. This would allow messages and variables to be treated more uniformily. Also perhaps getVariableProperty() and getVariableData could be depreciated. I suspect something like XML Algebra has a better way for expressing things like assignment and equality. BPEL talks about equality but does not give a good definition, or even a reference to its equality model. Cheers, Andrew
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]