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] Q: Assign semantics


Yuzo,

I sympathize with your feeling of discomfort in this area. I think the
current spec simply does not clearly distinguish nodes from values (in
XQuery 2.0 they would be called "atomic values"). In the following
paragraphs I'll discuss the way I try to rationalize this subject.

My first assumption is that any variable defined by a messageType only
deals with nodes and not values. This is because the variable only deals
with a whole message (which is an element node), or with a part (which
is also an element node) or with a query selection (which returns a
node), and that is the only stuff that WSDL defines. (So I think that
both your C2 and C3 are fine since both sides of the assignments are
nodes).

I would also expect that a variable defined by an element should follow
the previous case: it only deals with nodes (e.g. your second assignment
in Q1).

Let's now look at the "from expression" and "from literal" cases. It
would look like both cases only yield atomic values. (By the way, your
first assignment in Q1 should be fine, but the second one might not be
acceptable: can <somens:intElem>0</somens:intElem> qualify as a literal?
I would not think so).

If I have a variable defined by a type, what is the variable supposed to
contain? Both your first assignment in Q1 and C1 have atomic values in
their RHS. Does the variable contain a value after the assignment? Or
does it contain a node (assuming the value was converted to a node
before the assignment)?

If we look at the spec, some examples seems to be doing automatic
conversions from nodes to values and vice versa. For example, in sec.
16.2.2 the following assignment seems to take a string value and turn it
into an element of a simple string type:

<assign>
  <copy>
    <from expression="'yes'"/>
    <to variable="approval" part="accept"/>
  </copy>
</assign>

and in sec. 16.1.3 the following assignment takes the node returned by
getVariableProperty (as specified in 14.1) and converts it to a value in
order to perform the addition:

<assign>
  <copy>
    <from expression= "bpws:getVariableData('itemsShipped')
                     +
bpws:getVariableProperty('shipNotice','props:itemsCount')"/>
    <to variable="itemsShipped"/>
  </copy>
</assign>

Bottom line: I think the spec should clearly specify where values are
used, where nodes are used, and where automatic conversions, if any, are
allowed.

Ugo

> -----Original Message-----
> From: Yuzo Fujishima [mailto:fujishima@bc.jp.nec.com] 
> Sent: Tuesday, May 18, 2004 4:28 AM
> To: wsbpel@lists.oasis-open.org
> Subject: [wsbpel] Q: Assign semantics
> 
> 
> Hi,
> 
> Could someone help me better understand the semantics of <assign>?
> 
> 
> Q1: Are the following <from>'s legal?
>   ...
>   <variable name="intTypeVar" type="xsd:int"/>
>   <variable name="intElemVar" element="somens:intElem"/>
>   <!-- intElem is of type xsd:int -->
>   ...
>   <assign>
>     <copy>
>       <from>0</from>
>       <to variable="intTypeVar"/>
>     </copy>
>   </assign>
>   ...
>   <assign>
>     <copy>
>       <from><somens:intElem>0</somens:intElem></from>
>       <to variable="intElemVar"/>
>     </copy>
>   </assign>
> 
> I expect Yes for Q1.
> 
> Now, more difficult one.
> The example 16.1.3 of the specification contains the 
> following <assign>: Case C1:
>   ...
>   <variable name="itemsShipped" type="props:itemCountType"/>
>   ...
>   <assign>
>     <copy>
>       <from expression="0"/>
>       <to variable="itemsShipped"/>
>     </copy>
>   </assign>
> 
> Suppose part p1 of message type mt1 and part p2 of message 
> type mt2 are defined to be of the same XML schema type. 
> Further suppose we have variable v1 of type mt1 and v2 of mt2.
> 
> The following assign should be legal:
> Case C2:
>   <assign>
>     <copy>
>       <from variable="v1" part="p1"/>
>       <to variable="v2" part="p2"/>
>     </copy>
>   </assign>
> 
> Q2: Is the following legal?
> Case C3:
>   <assign>
>     <copy>
>       <from expression="bpws:getVariableData ('v1', 'p1')"/>
>       <to variable="v2" part="p2"/>
>     </copy>
>   </assign>
> 
> Assume the answer to Q2 is Yes. Then, I feel some 
> inconsistency: In C1 the expression is interpreted as the 
> value itself to be assigned while in C3 as a node set 
> containing a node whose content is to be assigned. (According 
> to 14.1 of the specification, the expression in C3 returns a 
> node set containing the single node representing the entire part p1.)
> 
> If p1 and p2 are of simple type, we can avoid this 
> inconsistency by saying that the from-expression node set is 
> promoted to a value and then assigned to p2. But this 
> interpretation doesn't apply if p1 and p2 are of complex type.
> 
> Assume the answer is No. I feel uncomfortable also in this 
> case because then it follows that
>   <from variable="v1" part="p1"/>
> has a different meaning from
>   <from expression="bpws:getVariableData ('v1', 'p1')"/>.
> 
> 
> Yuzo Fujishima
> NEC Corporation
> 
> 
> 
> To unsubscribe from this mailing list (and be removed from 
> the roster of the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le
ave_workgroup.php.



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