[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 138 - Properties of type element
Complex types for properties sound good, except for properties in
correlation sets. However, there is one more exception: when
getVariableProperty(...) is used in a condition, it seems that it should be
restricted to simple types as well. This limits the use of complex-typed
properties basically to assignments.
Kind Regards
DK
"Satish Thatte"
<satisht@microsof
t.com> To
<ygoland@bea.com>
21.07.2004 02:20 cc
<wsbpel@lists.oasis-open.org>
Subject
RE: [wsbpel] Issue - 138 -
Properties of type element
See my response to your question about issue 137 re the semantics of
properties. I am opposed to changing that.
That said, I have no issue with generalizing property types to allow
complex types SO LONG AS properties used in correlation sets are
restricted to simple types, to allow for performant implementation. I
understand how this helps reduce XPath clutter.
Satish
-----Original Message-----
From: Yaron Y. Goland [mailto:ygoland@bea.com]
Sent: Monday, July 19, 2004 10:40 AM
To: Satish Thatte
Cc: wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue - 138 - Properties of type element
One of the things I really enjoy about working on software platforms is
to see how users use features we have provided in ways we never
expected. We had just such an experience with properties.
It turns out that properties are an extraordinarily useful way of
allowing process architects to enable process programmers to interact
with complex XML structures in simple ways. Rather than forcing process
programmers to liter their BPELs with XPATHs the process architect can
define the key XPATHs for the structures the programmers need to
interact with and provide them as properties. The results have been most
gratifying.
To further enable such scenarios it would be very useful to expand
properties to support arbitrary types. This change would require no
alterations what so ever in our correlation mechanism.
This is one of the great situations where everyone wins. Correlation
still work just fine and users have access to a fantastic feature that
allows them to be more productive. I personally expect to see properties
become the preferred way to abstracting data structures for programmers.
It will become a core design pattern for BPEL.
Yaron
Satish Thatte wrote:
>
>
> This proposal represents a completely new interpretation of
properties.
> Properties are not general queries against data in XML messages. We
> already have a general query mechanism embedded independently of
> properties. Properties were specifically introduced for correlation
and
> the restriction to simple types is appropriate for that primary use
case.
>
>
>
> 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 - 138 - Properties of type element
>
>
>
> 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 - 138 - Properties of type element *
>
> * 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:* Properties are currently restricted to be simpleTypes
but
> in many cases being able to pull out structured information is
> extraordinarily valuable to users. One can imagine properties like
'list
> or order addresses' that goes through all the orders in a PO and
returns
> a list of all the address structures.
> *Submitter's proposal:* We should allow properties to be both
> simpleTypes and complexTypes.
> *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 - 138 - [anything]" or is a reply
to
> such a message. If you want to formally propose a resolution, please
> start the subject line "Issue - 138 - 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
.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]