Re: [wsbpel] Issue 197: Un-initializing BPEL variables

[Assaf Arkin <arkin@intalio.com>]

Yaron Y. Goland wrote:

> Bringing this back to 197, in the case of a complex type or element 
> type we could treat this as a delete which, given that the entire 
> contents of the variable is being deleted, would translate into an 
> uninitialized value. Note however that this means making null and 
> uninitialized effectively the same at the variable level. For example, 
> imaging having a complex type variable that can contain 0 to 5 <foo> 
> elements. Having no <foo> elements is legal and meaningful. So how 
> exactly do we create a complex type variable that is empty but not 
> uninitialized? I can't escape the thought that this is perhaps an edge 
> case not worth covering?

In my opinion, having an empty complex type is not an edge case, and 
forcing it to be un-initialized introduces complexity (no pun intended).

Let's say that I use a complex type to hold a list of items (0..n of 
<foo>), which I believe is a common use case. Before I can do anything, 
the variable needs to be initialized, so there's some activity (or set 
of) that put items into the variable. It's possible that these 
activities will put 2 items, or 5 items, or even no items. I cannot 
determine the count a priori.

If putting no-items in the variable simply means it's empty (the way we 
treat arrays and sets in other language), then anything pans out nicely. 
I can iterate over the child elements of the complex type and do 
something with each element; if the variable is empty then I have zero 
iterations. Or if I worry about the case where n=0, I can always check 
it with a simple expression. And, of course, I can put the value into a 
message and send it to a service that accepts an empty set.

If putting no-items in the variable means the variable is 
un-initialized, then now I have to worry about selection faults. 
Attempting to iterate over the variable will cause a selection fault; 
checking to make sure there are some elements will throw a selection 
fault; trying to send that value will throw a selection fault. So I need 
all those fault handlers to handle the empty value.


For me simple reads:

1. Take source value, assign it to target variable.
2. Empty is just another form of content.
3. If the target can accept the value, assign it*. Otherwise throw a fault.
4. To un-initialize a variable, use a specific operation that 
un-initializes it.

* The empty value needs to be type-checked like any other value, before 
assigning to a simple or complex type.

The only thing we know for sure is that empty cannot be assigned to an 
element. But even that is not a special case. Imagine an expression of 
the form '$foos/foo' with the target being an element of type foo. If 
the expression selects one element, the assignment works. If the 
expression selects any other number of elements, the assignment faults. 
Why should the case for n=0 be different from n>1?

Assaf

begin:vcard
fn:Assaf Arkin
n:Arkin;Assaf
org:Intalio
adr;dom:;;1000 Bridge Parkway Ste 210;Redwood City;CA;94065
email;internet:arkin@intalio.com
title:Chief Architect
tel;work:(650) 596-1800
x-mozilla-html:TRUE
url:http://www.intalio.com
version:2.1
end:vcard

S/MIME Cryptographic Signature