[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 103 - Moving Forward
That works for me also, although process wise I still it would be clearer
having a separate bug issue for the XPath binding.
Paco
"Yaron Y. Goland"
<ygoland@bea.com> To: Satish Thatte <satisht@microsoft.com>
cc: Danny van der Rijn <dannyv@tibco.com>, wsbpeltc
09/29/2004 07:55 <wsbpel@lists.oasis-open.org>
PM Subject: Re: [wsbpel] Issue - 103 - Moving Forward
Please respond to
ygoland
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]