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:]
Sent: Wed 9/29/2004 7:35 PM
To:
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:]
>> 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鴳e 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:]
>> > 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.
>
>
