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 - Good Idea!


maybe i just don't know XPATH well enough, but if $var/a/b/c doesn't exist,
can it be the target of an assign?

----- Original Message ----- 
From: "Maciej Szefler" <mbs@fivesight.com>
To: "Danny van der Rijn" <dannyv@tibco.com>; "wsbpeltc"
<wsbpel@lists.oasis-open.org>
Sent: Friday, March 12, 2004 10:10 AM
Subject: Re: [wsbpel] Issue 103 - Good Idea!


> Can you elaborate? I don't the connection.
>
> -maciej
>
> On Fri, 12 Mar 2004 09:56:51 -0800, Danny van der Rijn <dannyv@tibco.com>
> wrote:
>
> > even so, if we add the ability to have assign create new nodes (issue
> > 11),
> > then this syntax wouldn't work.
> >
> > ----- Original Message -----
> > From: "Maciej Szefler" <mbs@fivesight.com>
> > To: "Danny van der Rijn" <dannyv@tibco.com>; "wsbpeltc"
> > <wsbpel@lists.oasis-open.org>
> > Sent: Friday, March 12, 2004 9:52 AM
> > Subject: Re: [wsbpel] Issue 103 - Good Idea!
> >
> >
> >> This might not be a problem if it were possible to define copy
> >> assignment
> >> in terms of node-replacement operations;  then any expression that
> >> returns
> >> a node could act as an l-value to an assignment. Such a scheme could
> >> rely
> >> exclusively on schema-based type checking (with an implied schema for
> >> message variables).
> >> -maciej
> >>
> >>
> >> On Fri, 12 Mar 2004 09:12:04 -0800, Danny van der Rijn
> >> <dannyv@tibco.com>
> >> wrote:
> >>
> >> > i wouldn't think so, since $var refers to the value, not the
location.
> >> > but
> >> > being just a mere mortal, i am open to being corrected.
> >> >
> >> > ----- Original Message -----
> >> > From: "Satish Thatte" <satisht@microsoft.com>
> >> > To: "Maciej Szefler" <mbs@fivesight.com>; "Dieter Roller"
> >> > <ROL@de.ibm.com>
> >> > Cc: "Alex Yiu" <alex.yiu@oracle.com>; "Assaf Arkin"
> >> <arkin@intalio.com>;
> >> > "wsbpeltc" <wsbpel@lists.oasis-open.org>; <ygoland@bea.com>
> >> > Sent: Friday, March 12, 2004 8:52 AM
> >> > Subject: RE: [wsbpel] Issue 103 - Good Idea!
> >> >
> >> >
> >> > I imagine that expression= is as relevant to "to" as to "from" ..
> >> >
> >> >  -----Original Message-----
> >> > From: Maciej Szefler [mailto:mbs@fivesight.com]
> >> > Sent: Friday, March 12, 2004 8:47 AM
> >> > To: Dieter Roller; Satish Thatte
> >> > Cc: Alex Yiu; Assaf Arkin; wsbpeltc; ygoland@bea.com
> >> > Subject: Re: [wsbpel] Issue 103 - Good Idea!
> >> >
> >> > I haven't followed this discussion too closely, but am I correct in
> >> > inferring that if these suggestion were adopted, we could eliminate
> >> most
> >> >
> >> > of the from-specs in the assign activity? Could we normalize
> >> assignment
> >> > to
> >> > the following
> >> >
> >> >    <copy>
> >> >       <to variable="msgVar"/>
> >> >       <from expression="$otherMsgVar"/>
> >> >    </copy>
> >> >
> >> > could be used to assign a message variable.
> >> >
> >> >    <copy>
> >> >       <to variable="simpleTypeVar"/>
> >> >       <from expression="$msgVar/msg/simplePart"/>
> >> >    </copy>
> >> >
> >> >    <copy>
> >> >       <to variable="simpleTypeVar"/>
> >> >       <from expression="$otherSimpleTypeVar"/>
> >> >    </copy>
> >> >
> >> > could be used to assign a simple variable
> >> >
> >> >    <copy>
> >> >       <to variable="elementVar"/>
> >> >       <from expression="$msgVar/msg/elementPartType"/>
> >> >    </copy>
> >> >    <copy>
> >> >       <to variable="elementVar"/>
> >> >       <from expression="$otherElementVar"/>
> >> >    </copy>
> >> >
> >> > could be used to assign an element variable.
> >> >
> >> > -maciej
> >> >
> >> >
> >> >
> >> >
> >> > On Fri, 12 Mar 2004 07:23:35 +0100, Dieter Roller <ROL@de.ibm.com>
> >> > wrote:
> >> >
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> +1
> >> >>
> >> >> Cheers,
> >> >>
> >> >> dieter
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>              "Satish Thatte"
> >> >>              <satisht@microsof
> >> >>              t.com>
> >> >
> >> >> To
> >> >>                                        "Assaf Arkin"
> >> > <arkin@intalio.com>,
> >> >>              03/12/2004 05:14          "Alex Yiu"
> >> > <alex.yiu@oracle.com>
> >> >>              AM
> >> >
> >> >> cc
> >> >>                                        "wsbpeltc"
> >> >>
<wsbpel@lists.oasis-open.org>,
> >> >>                                        <ygoland@bea.com>
> >> >>
> >> > Subject
> >> >>                                        RE: [wsbpel] Issue 103 - Good
> >> >> Idea!
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> I am having trouble keeping up with this fast moving discussion.  I
> >> am
> >> >> hoping that you will reach an agreement and then educate the mere
> >> >> mortals among us on what the consensus proposal is ..
> >> >>
> >> >> Satish
> >> >>
> >> >>
> >> >>
> >> >> -----Original Message-----
> >> >> From: Assaf Arkin [mailto:arkin@intalio.com]
> >> >> Sent: Thursday, March 11, 2004 7:59 PM
> >> >> To: Alex Yiu
> >> >> Cc: wsbpeltc; Satish Thatte; ygoland@bea.com
> >> >> Subject: Re: [wsbpel] Issue 103 - Good Idea!
> >> >>
> >> >>
> >> >>> (4)
> >> >>> Assaf suggested:
> >> >>> In WSDL 2.0,
> >> >>> $variable/ns:element[/ns:subElement]
> >> >>> In WSDL 1.1,
> >> >>> $variable/partName/ns:element
> >> >>>
> >> >>> I was wondering whether it make sense to add a WSDL QNAME
> >> >>> (ns:wsdlMsgName) like the following for WSDL 1.1:
> >> >>>
> >> >>> $variable/ns:wsdlMsgName/partName/...
> >> >>>
> >> >>> then the syntax would be more symmetrically between WSDL 1.1 and
2.0
> >> >>> ns:wsdlMsgName => ns:element
> >> >>> partname => subElement
> >> >>>
> >> >>> The BPEL code migration may be easier from WSDL 1.1 to 2.0
> >> >>
> >> >> If anyone has a good handle on where WSDL 2.0 is heading with their
> >> >> message definition, would be great to throw some ideas around.
> >> Ideally
> >> >> if you have a WSDL 2.0 interface that's backward compatible with
WSDL
> >> >> 1.1, you could use the BPEL process with both 1.1 and 2.0 without
> >> >> change.
> >> >>
> >> >> Assaf
> >> >>
> >> >>
> >> >>
> >> >> 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_workgr
> >> > oup.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_workgr
> >> > oup.php.
> >> >>
> >> >
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> Maciej Szefler [mbs(a)fivesight.com] [+1-312-432-0556x226]
> >>
> >> 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.
> >
>
>
>
> -- 
> Maciej Szefler [mbs(a)fivesight.com] [+1-312-432-0556x226]
>
> 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]