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 - 103 - Moving Forward


Great.  And just to be clear, I remain strongly in favor of the simple $var_part solution to the problem of addressing XML content in message parts ..

________________________________

From: Alex Yiu [mailto:alex.yiu@oracle.com]
Sent: Wed 9/29/2004 7:35 PM
To: ygoland@bea.com
Cc: Satish Thatte; Danny van der Rijn; wsbpeltc
Subject: Re: [wsbpel] Issue - 103 - Moving Forward




I am OK with that all or nothing (in terms of $var syntax) commitment also.

Thanks!

Regards,
Alex Yiu


Yaron Y. Goland wrote:

> That commitment sits fine with me. Paco, does it work for you?
>
>     Yaron
>
> Satish Thatte wrote:
>
>>
>>
>> This is OK with me if we make a commitment that the eventual complete
>> resolution will either drop $ syntax or make it possible to use it
>> with all XML content in all variables including messagetype variables.
>>
>> -----Original Message-----
>> From: Yaron Y. Goland [mailto:ygoland@bea.com]
>> Sent: Monday, September 27, 2004 5:50 PM
>> To: Satish Thatte
>> Cc: Danny van der Rijn; wsbpeltc
>> Subject: Re: [wsbpel] Issue - 103 - Moving Forward
>>
>> The proposal would specify that the $ syntax would be available for
>> non-messageType variables only. For the moment I don't intend to
>> restrict getVariableData for messageType only variables because I hope
>> we will come up with a resolution for the messageType issue that allows
>> us to get rid of getVariableData.
>>
>> The point of having a partial proposal is to let us make progress. We
>> can agree on the parts we agree on and get them voted on and then use
>> that as a foundation for moving forward on the issues of messageType and
>> property access.
>>
>>         Yaron
>>
>> Satish Thatte wrote:
>>  >
>>  >
>>  > So if I understand this correctly, you are proposing that we do two
>>  > things with the partial resolution
>>  >
>>  > 1.  Allow BPEL variables of XML types/elements to be bound into XPath
>>  > using the $ notation
>>  >
>>  > 2.  Define the BPEL context for XPath more precisely including
>>  > differentiating normal vs join expressions
>>  >
>>  > I certainly support 2.  I am a bit concerned about a schizophrenic
>>  > resolution of variable binding.  One of the reasons I liked the $
>>  > notation was that it clearly defined the point of binding,
>> eliminating
>>  > any races (at least in my na´ve understanding of XPath) in cases of
>>  > multiple occurrences of getVariableData in an expression, which is
>>  > evaluated concurrently with updates to those variables.  Now we would
>>  > have a split brain on this issue.
>>  >
>>  > Satish
>>  >
>>  > -----Original Message-----
>>  > From: Danny van der Rijn [mailto:dannyv@tibco.com]
>>  > Sent: Monday, September 27, 2004 9:27 AM
>>  > Cc: wsbpeltc
>>  > Subject: Re: [wsbpel] Issue - 103 - Moving Forward
>>  >
>>  > +1
>>  >
>>  > Alex Yiu wrote:
>>  >
>>  >  >
>>  >  > A big +1 from me.
>>  >  >
>>  >  > Regards,
>>  >  > Alex Yiu
>>  >  >
>>  >  >
>>  >  > Yaron Y. Goland wrote:
>>  >  >
>>  >  >> Any time a proposal gets too big it can be difficult to make
>> progress
>>  >  >> because too many issues get mixed up together. As such I
>> propose that
>>  >  >> we break issue 103 into separate proposals, much as we did
>> with issue
>>  >  >> 10.
>>  >  >>
>>  >  >> The first proposal I think should go out for a vote would be a
>>  >  >> modified version of the current 103 proposal that removes the
>> WSDL
>>  >  >> binding to XPATH variables, keeps the getVariableData function
>> and
>>  >  >> doesn't change the current from-specs and to-specs.
>>  >  >>
>>  >  >> This proposal would just include the binding of non-WSDL BPEL
>>  >  >> variables to XPATH variables along with defining the XPATH
>>  >  >> environment in which various BPEL expressions execute.
>>  >  >>
>>  >  >> Then when we settle exactly how we would like to model WSDL
>> variables
>>  >  >> we can decide the future of getVariableData(), how WSDL variables
>>  >  >> will appear in XPATH (including any special forms for
>> doc/lit), if we
>>  >  >> would like to allow properties to be bound to variables, what
>>  >  >> from-spec and to-specs we want to use, etc.
>>  >  >>
>>  >  >> I believe that by breaking this problem up into discrete
>> issues we
>>  >  >> can make more rapid progress.
>>  >  >>
>>  >  >> What does the group think?
>>  >  >>
>>  >  >>     Thanks,
>>  >  >>
>>  >  >>         Yaron
>>  >  >>
>>  >  >> 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.
>>
>>  >
>>  >  >>
>>  >  >>
>>  >  >
>>  >  >
>>  >  >
>>  >  > 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.
>>
>>  >
>>  >  >
>>  >  >
>>  >  >
>>  >
>>  > 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.
>>
>>  >
>>  >
>>  >
>>  > 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.
>>
>>  >
>>  >
>>
>
> 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]