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