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


With limited thinking cycle spent in this topic, I would prefer have a special-form of from-spec to solve this problem: 

        <from a_new_attr_name="yes" />
        <!-- let's say, the attribute name is: "uninitialized" -->
       <to variable="x" />

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)

            <!-- sigh ... the verbose amendment here ... :-) ... -->
               <from> $varX/po:lineItem[10] </from>
               <to> $varY </to>

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.


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 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.


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


+44 (0) 1473 729537


+44 (0) 7801 948219//


+44 (0) 870 7390077


/www.choreology.com <http://www.choreology.com/>/


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

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