OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


I believe this should be handled the same way as if we had 
<staticValue>something</staticValue>. I mean, either it can assign a 
text node (empty or not) to the element variable, or it throws a fault. 
Otherwise, we have an exception for the case where the assigned value is 
character data, but happens to have a particular length.

Assaf

Yaron Y. Goland wrote:

> I'm fine having a special attribute and think it would be a fine part 
> of resolving this issue. But it still leaves open a question, what is 
> the consequence of:
>
> <assign>
> <copy>
> <from>
> <!-- Or whatever we agreed to call it in 111.1 -->
> <staticValue/>
> </from>
> <to variable="x" />
> </copy>
> </assign>
>
>
> Let's assume that variable X is of type element, specifically <Foo/>.
>
> What happens to X? Is it uninitialized? It can't be 'empty' because X 
> MUST contain an element named <Foo>, that is required by its nature as 
> an element variable. So what's left? We can either declare the above 
> to always be illegal or we can declare that it uninitializes the 
> variable or we can even try some interesting conversation routines 
> (e.g. treat the source as a text node intended to be made the child of 
> Foo) but we need to say something.
>
> Yaron
>
> Alex Yiu wrote:
>
>> Hi,
>>
>> With limited thinking cycle spent in this topic, I would prefer have 
>> a special-form of from-spec to solve this problem:
>> <assign>
>> <copy>
>> <from */a_new_attr_name/="yes"* />
>> <!-- let's say, the attribute name is: "*uninitialized*" -->
>> <to variable="x" />
>> </copy>
>> </assign>
>>
>> This uninitialized attribute just controls the special flag 
>> associated with a variable value to indicate whether a variable value 
>> has been assigned to that variable. Hence, we don't need to come up 
>> with special values which are valid to the associated varaible types 
>> to indicate the "uninitialized" status of the variable.
>>
>> For sake of argument, let's assume one implementation has the 
>> following extensions:
>>
>> * <foo:xcopy> which allows the from-spec yield zero nodes
>> * A variable type that can store the nodeset of XPath 1.0 or the item
>> sequence of XQuery 1.0. (That is, $varY)
>>
>>
>> For
>> <assign>
>> <extensibleAssign>
>> <!-- sigh ... the verbose amendment here ... :-) ... -->
>> <foo:xcopy>
>> <from> $varX/po:lineItem[10] </from>
>> <to> $varY </to>
>> </foo:xcopy>
>> </extensibleAssign>
>> </assign>
>>
>> It is a useful value for a variable to points to an empty result result.
>> So, we can do the following expression: "count($varY) > 0"
>> That is: we need to differentiate between an "empty-result-set" 
>> situation and "we-don't-have-a- result-set" situation.
>>
>> Similar semantics consideration would be applied to simple-type 
>> variables and WSDL message variable (the 
>> source-of-all-data-related-complication). [ Asking me to come up with 
>> a sensible XML Infoset to represent an uninitialized WSDL message 
>> would make my head hurt. :-) ]
>>
>> In short, IMHO, a special form of from-spec is the 
>> /_simplest-and-cleanest_/ solution to this problem.
>>
>> Thanks!
>>
>>
>>
>> Regards,
>> Alex Yiu
>>
>>
>>
>> Assaf Arkin wrote:
>>
>>> Yaron Y. Goland wrote:
>>>
>>>> Your argument works for text nodes but not elements and who says 
>>>> that the contents of a static value that contains nothing is a text 
>>>> node? That certainly isn't defined in the spec today. In fact we 
>>>> have at least 2 open issues on exactly this kind of problem.
>>>
>>>
>>>
>>> I made no such assumption. To assign a value to a text node I need 
>>> to obtain a string value, but if you read the XPath expression, I 
>>> can operate on a variety of content models in order to arrive at 
>>> that string value.
>>>
>>> Since I consider an empty value to be a valid and useful value, we 
>>> need a way to disambiguate between un-initializing a variable and 
>>> expressions that can assign an empty value to a text node. Since we 
>>> want to keep it simple, let's find an un-initializing mechanism that 
>>> is not node-type specific, and retain that distinction across all 
>>> node types.
>>>
>>> Assaf
>>>
>>>>
>>>> Assaf Arkin wrote:
>>>>
>>>>> In XML empty is still a content. An empty text node contains zero 
>>>>> characters. Different from nothing or null.
>>>>>
>>>>> For example, if I have the expression concat($X,$Y) it is valid 
>>>>> for Y to be empty, and its reasonable for someone to set it to 
>>>>> empty and be used. $Y needs to have a value in this case and the 
>>>>> expression need to evaluate.
>>>>>
>>>>> Un-initialize will require its own construct, a) to not confuse 
>>>>> between empty and null, and b) since we currently do not allow 
>>>>> null to be selected.
>>>>>
>>>>> Assaf
>>>>>
>>>>> Tony Fletcher wrote:
>>>>>
>>>>>> This issue has been added to the wsbpel issue list with a status 
>>>>>> of "received". The status will be changed to "open" if the TC 
>>>>>> accepts it as identifying a bug in the spec or decides it should 
>>>>>> be accepted specially. Otherwise it will be closed without 
>>>>>> further consideration (but will be marked as "Revisitable")
>>>>>>
>>>>>> The issues list is posted as a Technical Committee document to 
>>>>>> the OASIS WSBPEL TC pages 
>>>>>> <http://www.oasis-open.org/apps/org/workgroup/wsbpel> on a 
>>>>>> regular basis. The current edition, as a TC document, is the most 
>>>>>> recent version of the document entitled in the "Issues" folder of 
>>>>>> the WSBPEL TC document list 
>>>>>> <http://www.oasis-open.org/apps/org/workgroup/wsbpel/documents.php> 
>>>>>> - the next posting as a TC document will include this issue. The 
>>>>>> list editor's working copy, which will normally include an issue 
>>>>>> when it is announced, is available at this constant URL 
>>>>>> <http://www.choreology.com/external/WS_BPEL_issues_list.html>.
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------ 
>>>>>>
>>>>>>
>>>>>>
>>>>>> Issue 197: Un-initializing BPEL variables
>>>>>>
>>>>>> *Status:* received
>>>>>> *Date added:* 12 Mar 2005
>>>>>> *Categories:* Data Handling 
>>>>>> <http://www.choreology.com/external/WS_BPEL_issues_list.html#category_data_handling> 
>>>>>>
>>>>>> *Date submitted:* 11 March 2004
>>>>>> *Submitter:* Yaron Y. Goland <mailto:ygoland@bea.com>
>>>>>> *Description:* Is it legal/possible to un-initialize a variable 
>>>>>> in BPEL? What happens, for example, if one tries to assign a 
>>>>>> static from value that is empty? Should we allow for from-spec to 
>>>>>> be empty and have that mean that the target is uninitialized?
>>>>>> *Submitter’s proposal:* Being able to un-initialize variables is 
>>>>>> a generically useful thing. It makes it clear when a variable 
>>>>>> doesn't contain a 'useful' value. So I think we should provide a 
>>>>>> way to un-initialize variables.
>>>>>> *Changes:* 12 Mar 2005 - new issue
>>>>>>
>>>>>> ------------------------------------------------------------------------ 
>>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>> Tony/ /
>>>>>>
>>>>>> / <http://www.choreology.com/>/
>>>>>>
>>>>>>
>>>>>> Tony Fletcher
>>>>>>
>>>>>> Technical Advisor
>>>>>> Choreology Ltd.
>>>>>> 68, Lombard Street, London EC3V 9L J UK
>>>>>>
>>>>>> Phone:
>>>>>>
>>>>>>
>>>>>> +44 (0) 1473 729537
>>>>>>
>>>>>> Mobile:
>>>>>>
>>>>>>
>>>>>> +44 (0) 7801 948219//
>>>>>>
>>>>>> Fax:
>>>>>>
>>>>>>
>>>>>> +44 (0) 870 7390077
>>>>>>
>>>>>> Web:
>>>>>>
>>>>>>
>>>>>> /www.choreology.com <http://www.choreology.com/>/
>>>>>>
>>>>>> Cohesions™
>>>>>>
>>>>>> Business transaction management software for application 
>>>>>> coordination
>>>>>>
>>>>>> Work: tony.fletcher@choreology.com
>>>>>>
>>>>>> Home: amfletcher@iee.org <mailto:amfletcher@iee.org>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
>>> For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
>>>
>>
>
>

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]