Hi
I would also interprete <foo> as an XML Element node, NOT a text node in
this case.
Regards,
Alex Yiu
Assaf Arkin wrote:
> 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:
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>
>
