| Re: [bpel-dev] Query queryLanguage attribute |
Jonathan Coogan wrote:
Thanks for filing bugs :-)Thanks to Michal for fixing this already. The point above deals with runtime semantics of process execution.I have another question about Assigns and BPEL 2.0 compliance. I have seen several comments online about how the 2.0 spec requires that variables be initialized with literal values before they can be manipulated. I was looking through the spec for confirmation of this and found the following passages: 8.1 An attempt during process execution to read a variable or, in the case of a message type variable, a part of a variable before it is initialized MUST result in the standard bpel:uninitializedVariable fault. This includes the <invoke> and <reply> activity, where the presence of an uninitialized part also results in the standard fault bpel:uninitializedVariable. I think the best that the designer could do is to check if the variable which appears in any _expression_ has been on the LHS of any copy rule. This would be be an addition to the validator that could warn of such being the case. It is not, however, on the list of mandated static analysis checks that a design tool ought to perform It is impossible to enforce these things statically in all cases (consider conditional or flow cases as possible paths of execution). Again runtime semantics subject to some of the execution path issues above.8.4.2 Using <copy> to initialize variables When the destination selected by the to-spec in a <copy> operation is un-initialized, which is either an entire WS-BPEL variable or a message part, that destination MUST first be initialized before executing the replacement rules defined above, as if the following has been applied: * For complex type and simple type variables or message parts, initialize to a skeleton structure composed of a DII and an anonymous Document Element EII. * For element based variables or message parts, initialize to a skeleton structure composed of a DII and an Document Element EII with the name matching the element name used in variable declaration. This talks about initializing variables using the assign + copy and having un-initialized variables in the to-spec. I guess it seems confusing in that you are in fact trying to initialize the variable. To me it means that that in the absence of initialization being done before, there has to be some default initialization that will take place before the copy rules are applied. This is confusing! Are there any plans to add special handling for this to the BPEL designer? Thank you. -Jon On 7/20/07 5:03 AM, "Simon D Moser" <SMOSER@xxxxxxxxxx> wrote: -- Michal Chmielewski, CMTS, Oracle Corp, W:650-506-5952 / M:408-209-9321 "Manuals ?! What manuals ? Son, it's Unix, you just gotta know." |