[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: issue 111.1: Alternative proposal to vote
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...) ----------------------
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]