issue 111.1: Alternative proposal to vote

[Francisco Curbera <curbera@us.ibm.com>]

Here is my ammended proposal to vote. I believe I covered all changes to
the spec but it is possible that I may have overlooked something.

Alternative resolution to issue 111.1

Approach:
---------
Maintain the current BPEL 'standard' extensibility model by which all BPEL
elements are by considered extensible with both attribute and elements
(outside the BPEL namespace), except where explicitly noted otherwise; in
particular, in cases where additional (or 'non-standard') extensibility is
explicitly architected, a non-extensible wrapper element shall be
introduced to contain the architected extensions. This approach is applied
to the cases of extensible assignment operations and literal from
specifications in the current specification draft, and should be applied as
appropriate when incorporating new architected (non-standard) extensibility
points.

In the case of the resolution of issue 11.1, the modification (spelled
below in detail) states the following syntax for the assign activity:

<assign standard-attributes>
    standard-elements
    (<copy>+
       from-spec
        to-spec
    </copy>
    <extensibleAssign>
       ...assign-element-of-other-namespace...
    </extensibleAssign>) +
</assign>

In the case of <from>, literal assignment will use the following <from>
syntax:

<from>
  <literal> ... literal value ... <literal>
</from>


Changes to the current specification draft - detail.
---------------------------------------------------

# Changes to Section 6.2 (Structure of a business process)to incorporate
new assign syntax:

1. Replace the description and pseudo-syntax of the assign activity with
the following:

"The <assign> construct can be used to update the values of variables with
new data. An <assign> construct can contain any number of elementary
assignments, including <copy> assign elements or data update operations
defined as extension under other namespaces. The syntax of the assignment
activity is:

<assign standard-attributes>
    standard-elements
    (<copy>+
       from-spec
        to-spec
    </copy>
    <extensibleAssign>
       ...assign-element-of-other-namespace...
    </extensibleAssign>) +
</assign>"

# Changes to Section 9.3 (Assignment) to incorporate modified resolution of
issue 11.1:

1. At the end of the first paragraph in the section, change the last
sentence from,

"Finally, this activity can also be used to copy endpoint references to and
from partner links."

to

"This activity can also be used to copy endpoint references to and from
partner links. Finally, it is possible to include extensible data
manipulation operations defined as extension elements under namespaces
different from the WS-BPEL namespace."

2. Change the pseudo-syntax for the assign activity as in Section 6.2.

3. Change the first sentence in the paragraph following the pseudo syntax
code from

"The assign activity copies a type-compatible value from the source
("from-spec") to the destination ("to-spec")."

to

"The assign activity allows copying a type-compatible value from the source
("from-spec") to the destination ("to-spec"), using the <copy> element."

4. Add the following paragraph right before the beginning of Section 9.3.1:

"In addition to <copy> specifications, other extensibility data
manipulation elements MAY be included in an assign activity, inside an
<extensibleAssign> element. The extensible assign elements MUST belong to a
namespace different from the WS-BPEL namespace. Note also that the
<extensibleAssign> element does not allow standard extensibility."

Changes to Section 9.3 (Assignment) to modify literal version of <from>:

1. Change pseudo syntax specification of the <from> element, from

"<from> ... literal value ... </from> "

to

"<from>  <literal> ... literal value ... <literal></from>"

2. Change the second to last paragraph in the section (right before the
start of Section 9.3.1),

from

"The fifth from-spec variant allows a literal value to be given as the
source value to assign to a destination. The type of the literal value MUST
be the type of the destination (to-spec). The type of the literal value MAY
be optionally indicated inline with the value by using XML Schema's
instance type mechanism (xsi:type)."

to

"The fifth from-spec variant allows a literal value to be given as the
source value to assign to a destination. The type of the literal value MUST
be the type of the destination (to-spec). The literal value to be assigned
is included within a <literal> element nested under the <from> element
itself in order prevent conflicts with standard extensibility elements
under <from>; note that the <literal> element itself does not allow
standard extensibility. The type of the literal value MAY be optionally
indicated inline with the value by using XML Schema's instance type
mechanism (xsi:type). "


Changes to the schema: update as above (sorry, it's getting to be a bit
late to start writing XSD...)
----------------------