[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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]