[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 197: Un-initializing BPEL variables
Is there a presumption that anything in a literal is a text node?
E.g. is:
<literal>
<foo>
<bar/>
</foo>
</literal>
A text node? Or is it a XML document?
Yaron
Alex Yiu wrote:
> Hi, Yaron and Assaf,
>
> Regarding to the following syntax, I have some second thought ... [ sorry about
> that :-) ]
> ------------------------------------
> <assign>
> <copy>
> <from>
> <literal />
> </from>
> <to variable="x" />
> </copy>
> </assign>
> ------------------------------------
>
> I have doubled checked XPath 2.0 data model (section 6.7). It explicitly
> disallows a text node with zero length.
>
> Therefore, the more suitable interpretation of the value returned by <literal>
> should be an empty nodeset. Of course assigning an empty nodset to /some /kinds
> of BPEL variables could make sense in /some /condition. However, to avoid catch
> all the corner cases and to maintain consistent semantics of "selectionFailure"
> fault, I think we should outlaw the above usage for XPath 1.0 for now. When we
> officially move to XPath 2.0 data model, we can consider enable the above usage.
>
> Thought?
> Thanks!
>
>
> Regards,
> Alex Yiu
>
>
>
>
>
> Alex Yiu wrote:
>
>>
>> Hi, Yaron,
>>
>> You have raised a good question.
>>
>> Using 111.1 syntax:
>> <assign>
>> <copy>
>> <from>
>> <literal />
>> </from>
>> <to variable="x" />
>> </copy>
>> </assign>
>>
>> Remember <literal /> = = = <literal></literal>
>>
>> Here is my attempt to answer your question:
>>
>> IMHO, the "empty" literal should yield a empty text-node (similar to empty str).
>> (Of course, the other option is to outlaw it.)
>>
>> If x is of a simple type which can accepts an empty string, the above
>> assignment should be legal.
>>
>> If x is of element or complex type of which has *simple-content* which is
>> derived , there may be cases where this assignment is legal. It depends on
>> Issue 157 - "Cleaning up copy".
>> See an example below: (note this part of decision belongs to 157 , not 197)
>>
>>
>> Before the assignment: x = = <foo:bar>*abc*</foo:bar>
>> After the assignment: x = = <foo:bar></foo:bar> ( = = = <foo:bar />)
>>
>>
>>
>>
>> Thanks!
>>
>>
>> Regards,
>> Alex Yiu
>>
>>
>
>
> Assaf Arkin wrote:
>
>> 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
>>>>>
>>>>
>>>
>>>
>>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]