Issue - 2 - subfunctions inside or outside of files

["Yaron Goland" <ygoland@bea.com>]

Chris's response to my e-mail brought up the issue of - should subfunctions
(or as Chris calls them, subprocesses) be defined only external to a BPEL
file or both inside of a BPEL file and in an external file?

There are two reasons why I think we should allow subfunctions to be defined
both inside of a BPEL file as well as outside of it:

	Visibility - As I will demonstrate in the example below allowing
subfunctions to be defined inside of a BPEL allows for the use of BPEL's
scoping rules so it is possible to make a subfunction declaration truly
private. This is a feature that every language ends up adding at one point
or another so I figure we should just get ahead of the curve.

	Organization - I find that when it comes to files my customers fall into
two broad camps. You have the proliferators who can never get enough files.
These are people who would define every method in every class in a separate
file if they could. Then you have the compactors, these are people who hate
file proliferation and want to put as much as possible into a single file.
By allowing subfunctions to be defined both inside and outside of the BPEL
file we can make both groups happy with little added complexity beyond that
already required to deal with visibility.

I propose that the way we import subfunction definitions is by using the
import feature implemented as a consequence of Issue 7. I think we should
define a new importType I will call
http://www.oasis.com/2003/wsbpeltc/subfunctionimport.

Imported subfunctions MUST be contained in a subfunction file. This is an
XML file whose root element is subfunctiondeclaration and whose contents are
subfunction elements. An example is given below.

When importing a subfunction file all the subfunctions declared in that file
are treated as if they were copied into the global scope of the process that
made the import.

The example below consists of two files. There is a subfunction file that
defines two functions, e1 and e2. Only e1 will be used in the example, I
only include e2 just to drive home the point that a subfunction file can
contain an arbitrary number of subfunctions. There is also a BPEL process
file which imports the subfunction file. Inside of the BPEL process file is
a scope and in that scope a subfunction also called e1 is defined. The point
is to show that name visibility rules apply so that if e1 is called from
inside of the scope then it will be the e1 defined in the scope but if e1 is
called from outside of the scope then it will be the e1 imported into the
global scope.

<subfunctiondeclaration name="eFunctions"
xmlns="http://www.oasis.com/2003/wsbpeltc/subfunctiondeclaration";>
   <subfunction name="e1">
      ...
   </subfunction>
   <subfunction name="e2">
      ...
   </subfunction>
<subfunctiondeclaration>

1 <process>
2    <bpel:import location="eFunctions"
importType="http://www.oasis.com/2003/wsbpeltc/subfunctionimport"/>
3    ...
4    <sequence>
5        <scope>
6           <subfunction name="e1">
7              ...
8           </subfunction>
9           <function functionName="e1"/>
10       </scope>
11       <function functionName="e1"/>
12    </sequence>
13 </process>

The function call in line 9 will call the function defined in line 6. The
function call in line 11 will call the function defined in the eFunctions
file that was imported in line 2.