RE: [wsbpel] Issue - 137 - Making properties consistent with variable values

["Satish Thatte" <satisht@microsoft.com>]

I had a private chat with Yaron on this and it turns out that I was misinterpreting his ideas based on wording like "the value of the POCount property is set to 1".  Yaron's interpretation of properties is identical to mine -- the problem he is thinking of is the much more subtle one of properties that evaluate to L-values vs those that don't.  He can clarify this much more eloquantly than I can but I did point out that trying to solve the L-value, R-value problem in property definitions would be a far larger headache than it would be worth -- my thought would be to tighten up the notion of property aliases to make the problem go away.
 
But I await Yaron's clarification to make that point more clearly.
 
Satish

________________________________

From: Satish Thatte [mailto:satisht@microsoft.com]
Sent: Tue 7/20/2004 5:16 PM
To: ygoland@bea.com
Cc: wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue - 137 - Making properties consistent with variable values



There is no such thing as an independent value for the POCount property.
This notion of a standalone property like POCount as a thing with a
value that could be used later existed in WSCI but never in BPEL.

The POCount property only has a value *relative to* a message.  Thus
there can (obviously) be many messages available to a process
simultaneously, each of which has a POCount property.  There is NO
notion that receiving every such message "resets the value of" the
POCount property. 

That is why, in assignment, you cannot use just a property name as
source or destination.  It is always relative to a message variable.

The thing that does have an independent (and immutable) value is a
correlation set.  When a message that initiates such a set is received,
the value of the cset is initialized/set to the appropriate
member-property values.  This does not set values for individual
properties on their own, only relative to the cset. 

This last para is a summary of what issue 8 was proposing to clarify.

Does that help?

-----Original Message-----
From: Yaron Y. Goland [mailto:ygoland@bea.com]
Sent: Monday, July 19, 2004 9:59 AM
To: Satish Thatte
Cc: wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue - 137 - Making properties consistent with
variable values

Satish,

        I'm sorry Satish but I don't understand the point you are trying
to
make in your mail. I therefore have produced below a detailed step by
step example of how I understand properties to work in BPEL today. Can
you please explain which of the assumptions below you feel is incorrect
and then provide your own version of this example showing the correct
behavior?

...
    bpws:property name="POCount" type="xs:int"
    bpws:propertyAlias propertyName="POCount" messageType="PO" /
                       part="First" query="count(/POOrders/Order)"

process
    ...
    sequence
       [1] receive partnerLink="foo" operation="incoming" /
                   variable="Orders"...
       [2] assign
              copy
                 from
                    "<POOrders><Order/><Order/></POOrders>"
                 to variable="Orders"

[1] When the message is received the properties associated with that
message are initialized using the propertyAlias definitions. In this
case the received message was: <POOrders><Order/></POOrders>. Therefore
the value of the POCount property is set to 1.

[2] The programmer now changes the contents of the variable Orders to
contains two orders. However this does not cause any change to the
POCount property. Therefore the property's value is still set to 1.

        Thanks,

                        Yaron  

Satish Thatte wrote:

>
>
> This issue represents a misunderstanding of the semantics of
properties
> in BPEL.
>
> 
>
> Properties are not akin to variables and are not set nor do they exist

> independently.  A property "occurs" in a message.  One can already get

> and set it in a message through getVariableProperty and property
> assignment.  Thus the fragment " the variable is edited to change one
PO
> into two. Now the NumOrder property, still set to the value 1 "
> illustrates the misunderstanding.
>
> 
>
> Only correlation sets have independently set values, and they are set
at
> the time of a web service interaction only.
>
> 
>
> Perhaps Issue 8 was not redundant after all ..
>
> 
>
> Satish
>
> 
>
> 
>
> * From: * ws-bpel issues list editor
[mailto:peter.furniss@choreology.com]
> *Sent:* Wednesday, July 14, 2004 8:01 PM
> *To:* wsbpel@lists.oasis-open.org
> *Subject:* [wsbpel] Issue - 137 - Making properties consistent with
> variable values
>
> 
>
> This issue has been added to the wsbpel issue list. 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 - 137 - Making properties consistent with variable values
*
>
> * Status: * open
> *Categories:* Syntax and validation <#category_syntax_and_validation>
> *Date added:* 15 Jul 2004
> *Submitter:* Yaron Y. Goland <mailto:ygoland@bea.com>
> *Date submitted:* 15 July 2004
> *Description:* Currently a property's value is set when a variable is
> initially set. If the variable's value is subsequently changed then
the
> property's value is not updated. Instead, once the property has been
> initially set, the state of the property and the state of the
underlying
> variable are no longer correlated. Allowing for a disconnect between
the
> property and its variable is all but guaranteed to lead to
> misunderstandings.
>
> Imagine a variable that contains a purchase order and the NumOrder
> property which contains a count of how many orders are in the PO . Now

> imagine that after the variable is set and the property initialized
then
> the variable is edited to change one PO into two. Now the NumOrder
> property, still set to the value 1, will no longer have the correct
> count of orders in the variable.
> *Submitter's proposal:* 1) We should require that any time a
variable's
> value is updated (e.g. with assign) that the property alias for all
the
> properties on the variable should be re-run so the property values
will
> be updated.
>
> 2) We should either ban assigning directly to properties or we should
> specify that properties that are not LValues (e.g. resolve to a single

> node in the underlying variable) are read-only and properties that are

> LValues can be written to but the consequence of doing so is that the
> node in the underlying variable is changed.
> *Changes:* 15 Jul 2004 - new issue
>
> To comment on this issue, please follow-up to this announcement on the

> wsbpel@lists.oasis-open.org list (replying to this message should
> automatically send your message to that list), or ensure the subject
> line as you send it *starts* "Issue - 137 - [anything]" or is a reply
to
> such a message. If you want to formally propose a resolution, please
> start the subject line "Issue - 137 - Proposed resolution", without
any
> Re: or similar.
>
> To add a new issue, see the issues procedures document (but the
address
> for new issue submission is the sender of this announcement).
>
> 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/leave_workgr
oup.php.
>

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/leave_workgroup.php.