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] Issue - 138 - Properties of type element


Why would it be necessary to limit getVariableProperty to only returning 
simple types? It is legal in XPATH to perform full path navigation on 
the return values of functions. E.g. getVariableProperty(...)/foo/bar is 
legal in so far as I'm aware.

	Yaron

Dieter Koenig1 wrote:

> 
> 
> 
> 
> 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]