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 - 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_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]