Re: [wsbpel] Issue 11 - Creation of Repeating/Optional XML Structures

[Danny van der Rijn <dannyv@tibco.com>]

i'd like to propose taking a "sense of the committee"/straw poll at the next
teleconference to see if we should move forward trying to solve this issue,
or leave it to vendors to extend if they see fit.

the wording for that would be something like "does the committee want to try
to resolve issue 11" (or should it be closed with no action).

danny

----- Original Message ----- 
From: "Kristofer Agren" <kagren@pakalert.com>
To: "'Green, Alastair J.'" <Alastair.Green@choreology.com>; "'Satish
Thatte'" <satisht@microsoft.com>; <edwink@collaxa.com>; "'Pal Takacsi-Nagy'"
<pal@bea.com>; "'Danny van der Rijn'" <dannyv@tibco.com>
Cc: <wsbpel@lists.oasis-open.org>
Sent: Thursday, February 05, 2004 7:33 AM
Subject: RE: [wsbpel] Issue 11 - Creation of Repeating/Optional XML
Structures


> This also falls slightly into the domain of issue# 90 where it is
suggested
> to add a feature to allow for loading static XML documents directly into a
> variable. Being able to read a configuration file of endpoint references
> would be key to allow for repeated invocations of the same Web Service
> method definition on different endpoints.
>
> Once the XML data of all the endpoints are loaded into a variable, you
could
> invoke each endpoint in a <while> loop, albeit they would not be invoked
in
> parallel.
>
> Kristofer
>
> -----Original Message-----
> From: Green, Alastair J. [mailto:Alastair.Green@choreology.com]
> Sent: Wednesday, February 04, 2004 5:47 AM
> To: Satish Thatte; edwink@collaxa.com; Pal Takacsi-Nagy; Danny van der
Rijn
> Cc: wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] Issue 11 - Creation of Repeating/Optional XML
> Structures
>
> If the current spec does not support the ability to read some
> configuration of n counterpart services, traverse that array and invoke
> on those services, and then cause delivery of that array to some other
> service or function, then I think Danny is right to say that BPEL is
> crippled. Is this not the subject of Issue 4 (an original submitters'
> issue), as well as this issue?
>
> We have a standard demo, where a hedge fund connects to (configurable) n
> market makers, and requests quotes for securities or options (ideally in
> parallel). We then examine the results and make a decision as to which
> (single) security and which (single) option we want to select. This
> selection would involve transmission of an order message to the selected
> market makers for each of the security and the option.
>
> How would this simple process be modelled in the current form of BPEL?
>
> Alastair
>
> -----Original Message-----
> From: Satish Thatte [mailto:satisht@microsoft.com]
> Sent: 04 February 2004 00:53
> To: edwink@collaxa.com; Pal Takacsi-Nagy; Danny van der Rijn
> Cc: wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] Issue 11 - Creation of Repeating/Optional XML
> Structures
>
> I really like Edwin's suggestion of letting the XML data manipulation
> standards work be done properly where it belongs.  We would be foolish
> to take on some arbitrary subset and address that in an ad hoc and
> separate effort from the mainline XML efforts.
>
> We already made sure that we can open up to those future standards by
> resolving Issue 13 the way we did.  Let us not open this can of worms.
>
> Satish
>
> -----Original Message-----
> From: Edwin Khodabakchian [mailto:edwink@collaxa.com]
> Sent: Tuesday, February 03, 2004 12:11 PM
> To: 'Pal Takacsi-Nagy'; 'Danny van der Rijn'
> Cc: wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] Issue 11 - Creation of Repeating/Optional XML
> Structures
>
> Data manipulation is indeed a must have which people usually address by
> calling out (through web service invocation or XPATH function call) to a
> transformation service implemented in XQuery, XSLT, XML Beans, etc.
>
> Usability could be greatly improved through the mechanism Alex is
> suggesting
> but it would also introduce a lot of details/issues to be ironed out. So
> the
> question is not should we do it or not but should we do it now or wait
> for
> the next revision of the spec.
>
> Edwin
>
>
> -----Original Message-----
> From: Pal Takacsi-Nagy [mailto:pal@bea.com]
> Sent: Tuesday, February 03, 2004 11:38 AM
> To: edwink@collaxa.com; 'Danny van der Rijn'
> Cc: wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] Issue 11 - Creation of Repeating/Optional XML
> Structures
>
> Doesn't not having proper support for data manipulation will result in
> incompatible implementation in BPEL? In can't think of any real life
> workflow that does not have data transformation in it.
> If all vendors have to do it their own way this will compromise the
> value of
> the standard IMHO.
>
> -----Original Message-----
> From: Edwin Khodabakchian [mailto:edwink@collaxa.com]
> Sent: Tuesday, February 03, 2004 11:13 AM
> To: 'Danny van der Rijn'
> Cc: wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] Issue 11 - Creation of Repeating/Optional XML
> Structures
>
> Danny,
>
> There is now doubt that today BPEL is crippled because it only supports
> very
> limited data manipulation (data initialization, array/looping, update).
> There is also no doubt that this is a slippery slope.
>
> One option might be to allow tighter integration between BPEL and XQuery
> (as
> suggested by Alex Yiu earlier in this forum).
>
> But even that integration work might be out of the scope of the initial
> delivery of the spec as this is something that can be layered on at a
> later
> point of time without impacting to our current work.
>
> Edwin
>
> -----Original Message-----
> From: Danny van der Rijn [mailto:dannyv@tibco.com]
> Sent: Tuesday, February 03, 2004 10:33 AM
> To: wsbpel@lists.oasis-open.org
> Subject: [wsbpel] Issue 11 - Creation of Repeating/Optional XML
> Structures
>
> At our September F2F, I presented some alternatives for addressing issue
> 11.
> The alternative were met with some opposition to even addressing the
> issue
> at all.  In order to get the conversations going again, I'd like to
> present
> a very high level view of the pros and cons of addressing the issue.  It
> seems most appropriate to me to begin at this level, before spending any
> more time actually trying to solve the issue.
>
> The issue:  To modify a variable's XML structure, one uses the <assign>
> <from/> <to variable="ncname" part="ncname"? query="queryString"?/>
> </assign> syntax.
>
> "For XPath 1.0, the value of the query attribute MUST be an absolute
> locationPath (with '/' meaning the root of the document fragment
> representing the entire part). It is used to identify the root of a
> subtree
> within the document fragment representing the part. The location path
> MUST
> select exactly one node. If the location path selects zero nodes or more
> than one node during execution, then the standard fault
> bpws:selectionFailure MUST be thrown by a compliant implementation."
>
> What this ends up meaning is that if there is a repeating element that
> has N
> instances of the element, the N+1th may not be created.  Additionally,
> if
> there is an optional element that is not present, it can not be created.
>
> Pro-Issue 11:  There are many use cases where the creation of repeating
> and/or optional elements is required.  A notable one is looping over an
> array of inputs, calling a service on each one, and creating an array of
> outputs.  There are many more.  BPEL would be crippled without this
> feature.
>
> Anti-Issue 11:  BPEL has some very primitive data handling capabilities,
> but
> should never have full-blown data handling capabilities.  If the
> language is
> modified to solve this problem, we are starting down a slippery slope.
> What
> will the next data handling addition be?  When will the ocean be boiled?
> If
> data handling capabilites beyond what are currently included are needed,
> then simply call out to a data handling/modification service.
>
>
> 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.
>
>
>
>
> 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.
>
>
> 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.
>