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


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]