Re: [wsbpel] Issue - 11 Your opinion requested

[Ron Ten-Hove <Ronald.Ten-Hove@Sun.COM>]

Danny,

    I've been assuming that the major use case for "complicated" assign operations would be to construct new messages from the bits and pieces in the instance's variables. The major "simple" assignment operations would consist of extracting simple values or perhaps an XML fragment at best.

    What you are suggesting is different: that we can use incrementally assemble an XML variable, perhaps even over several separate <assign> activities. I believe some use cases have already been suggested that could benefit from this capability. I wonder how would this work with serializable scopes? What does the TC think of this as a requirement for assignment operations?

Danny van der Rijn wrote:

From: "Ron Ten-Hove" <Ronald.Ten-Hove@Sun.COM>
  

    Neither solution will be very good at complex transformations; the
term painful comes to mind. (I suggest that for such transformations we
should use existing solutions like XSLT, and keep in mind emerging ones,
like XQuery.)
    

neither proposal was meant to do the things that XSLT can do.  i fully
support the issue to add XSLT support to BPEL.  however, there is, IMO, a
great need for something to provide small, local manipulations to XML trees.
something along the lines of the <assign> activity, but not quite so
crippled.  XSLT is too heavyweight to use for a simple append operation, for
instance.

Perhaps we are all awaiting XQuery to be finalised? :-)

     Finally, both solutions embrace a decidely imperative approach to
defining the tree structure of a result, when the <assign> activity
itself can contain the tree structure desired in a declarative fashion
that is far easier to create and read. Something along the lines of

    <node from=...>          <!-- root node -->
       <node from=.../>      <!-- 1st child of root node -->
       <node from=...>       <!-- 2nd child of root node; or
                                  following sibling to 1st child -->
          <attr from=.../>   <!-- attribute for 2nd child -->
       </node>
    </node>

    

again, this would be fine for *constructing* data, but for simple
modifications, it would be too heavyweight.  

Agreed, this is a way of constructing XML data, including XML fragments. Such fragments could be added to an existing (XML) variable:

    <from><node> ... construct fragment as above ... </from>
    <to variable="a" select="/foo/bar/baz/" action="append"/>

I'm not sure where the comment that the approach would be "too heavyweight" comes from. As a construction technique, it is arguably lighter weight than a DOM-like set of operations, but not by a lot. Both create a lot of coupling between the <assign> activity and the document types, as you note about the strawman:

it may also require a lot of
knowledge of what the data looks like, which might not be desirable.
  

I would submit that the two proposed solutions to this issue also suffer (to some degree) from this final property: they require a lot of knowledge about specific document structures. Changing document types will almost certainly require changes to the process definition. If we look at BPEL message properties, we find an agreeable mechanism for decoupling the process definition from the message data types. It would be nice to preserve this helpful attribute throughout BPEL.

Cheers,
-Ron