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
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
---------------------------------------------------------------------
To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
|