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 11 - Call for Discussion


i agree that we don't want to solve it that way.  if you look back at this
conversation from september (?) you will find other proposals.  the one that
sticks in my mind was yaron's (?) proposal to only validate xml when using
it in an invoke.  makes a certain amount of sense to me.  not that i'm
advocating it at the moment.

danny

----- Original Message ----- 
From: "Alex Yiu" <alex.yiu@oracle.com>
To: "Danny van der Rijn" <dannyv@tibco.com>
Cc: "Wsbpel@Lists. Oasis-Open. Org (E-mail)" <wsbpel@lists.oasis-open.org>
Sent: Tuesday, March 02, 2004 2:02 PM
Subject: Re: [wsbpel] Issue 11 - Call for Discussion


>
> Hi, Danny,
>
> I think a local (not-network-based) WS is one of answers. (e.g.
> WSDL-WSIF local binding)
>
> We need to be cautious. Otherwise, we may run into:
> (a) doing a list of cascade invention of new BPEL constructs: e.g.: the
> "magic" scope, <forEach>, and etc (Note: forEach already overlaps
> XQuery's "for" clause) - that is the slippery slope situation
> (b) that list of cascade invention would become a XML manipulation
> sub-language which does not take consideration from other technologies
> and requirements viewpoint (e.g. data update on multiple XML documents,
> instead of just one). BPEL developers would be tempted to express their
> complicated XML mainpulation logic in that sub-language in BPEL, which
> in turn makes it difficult for vendors to leverage other technologies to
> optimize the executation of BPEL.
>
> Thanks.
>
>
> Regards,
> Alex
>
>
>
> Danny van der Rijn wrote:
>
> >while i agree with the slippery slope argument, i think we need to come
up
> >with SOME answer to the usecase that yaron brings up (and that i think we
> >discussed somewhat in the september timeframe).
> >
> >danny
> >
> >----- Original Message ----- 
> >From: "Alex Yiu" <alex.yiu@oracle.com>
> >To: <ygoland@bea.com>
> >Cc: "Ron Ten-Hove" <Ronald.Ten-Hove@Sun.COM>; "Wsbpel@Lists. Oasis-Open.
Org
> >(E-mail)" <wsbpel@lists.oasis-open.org>; <ALEX.YIU@oracle.com>
> >Sent: Tuesday, March 02, 2004 1:09 PM
> >Subject: Re: [wsbpel] Issue 11 - Call for Discussion
> >
> >
> >
> >
> >>Hi all,
> >>
> >>I think Yaron's usecase (while+appendChild) is a valid one, which the
> >>atomicity of assign cannot help much in "schema inconsistent state
> >>situation". :-)
> >>
> >>However, as I mentioned before, BPEL community needs to recognize and
> >>agree that the 3 operations (e.g. insertBefore and appendChild)
> >>potentially added by issue 11 are NOT aimed to solve ALL XML
> >>manipulation problems. Those 3 operations are aimed at simple XML
> >>manipulation, NOT complicated ones.
> >>
> >>I think it is a good idea to make simple XML manipulation possible in
> >>BPEL and leave complicated XML manipulation to other languages. So, we
> >>will NOT run into a slippery slope situation and re-invent wheels for
> >>other emerging standards. (e.g. XUpdate)
> >>
> >>IMHO, it is perfectly fine for us to say some usecases of
> >>while+appendChild cannot be performed by the BPEL language itself. There
> >>may be semantic (e.g. this schema inconsistent state situation) and
> >>performance deficiency to perform those complicated XML manipulation in
> >>BPEL.
> >>
> >>One situation that I want to avoid is:
> >>A user just wants to do a simple insert into an existing document. There
> >>is no standard mechanism that BPEL specifies to do that. That user is
> >>forced to choose a potentially non-portable language or language binding
> >>to do just this extremely simple operation. Then, BPEL will end up in a
> >>close-to-zero portability situation.
> >>
> >>
> >>Thanks for reading this email!
> >>
> >>
> >>
> >>Regards,
> >>Alex Yiu
> >>
> >>
> >>
>
>



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