Yaron Y. Goland wrote:
> 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?
I made the assumption that he content of the literal element is an XML
tree, not a textual representation of that tree, and used that to
validate my proposal. So in this case my answer is, 'foo' is not a text
node.
Assaf
>
> 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:>
>>>>>>>>> *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:
>>>>>>>>>
>>>>>>>>> Home: <mailto:>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> To unsubscribe, e-mail:
>>>>>> For additional commands, e-mail:
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
>
