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: [wsbpel] Issue 157 - proposal draft


Hi all,

This is the proposal draft for Issue 157.
I will try to move it to a formal proposal within a couple of business days.

Thanks!

Regards,
Alex Yiu
Title: Issue 157 - Proposal

Issue 157 -  Proposal Draft


Last modified: July 29, 2005 - 1 pm PDT
 

(A) Clean up section "Type Compatibility in Assignment" (formally numbered as 9.3.1)

Note:
 
Details of Changes:
Under section "Type Compatibility in Assignment" (formally numbered as 9.3.1):

Change the section title from:  "Type Compatibility in Assignment"  to "Type Compatibility in Copy Operations"

Refine the first paragraph and first two bullets as follows (the inserted texts are highlighted by underlines)
--------------------------
For a copy operation to be valid, the data referred to by the from and to specifications MUST be of compatible types. The following points make this precise:

--------------------------


Change the third bullet and last paragraph FROM:
----------------------------------

The semantics of a process in which any of the matching constraints above is violated is undefined.
----------------------------------
TO:
----------------------------------
----------------------------------

(B) Insert a new section on "Selection Result of Copy Operations"

Insert a new section on "Selection Result of Copy Operations" before the section of "Type Compatibility ..." to state the replacement and XML information item nature of <copy>. Here is the details of that section:

----------------------------------
Selection Result of Copy Operations

There are 11 different types of information items in the XML Infoset model. Most of them are not relevant in the context of XML data manipulation as performed by <copy> operation. For example, Process Instruction Information Item, Comment Infirmation Item and Document Type Declaration Information Item.

The selection result of the from-spec and to-spec used within <copy> operation MUST be one of the following three information items: Element Information Item (EII), Attribute Information Item (AII) or Text Information Item (TII). Note: EII and AII are defined in [Infoset], while TII is defined to bridge the gap between Inforset Model and other common XML data model, such as, XPath 1.0 data model. Please see detailed definition of TII below.

If the selection result of a from-spec or a to-spec belongs to other kinds of data items, a bpws:selectionFailure fault MUST be thrown. Note that if any of the unsupported Information Items are contained in the selection result they will be preserved, the restriction is only that they cannot be selected directly as the top level item by the from-spec or to-spec.

Definition of Text Information Item (TII):
Text Information Item (TII) is a sequence of zero or more CII according to the document order. When it is mapped to XPath 1.0 model, it is a generalization of String-Value (which has zero or more characters) and Text Node (which has one or more characters). RValue of a TII can be mapped to a String-Value or a Text Node in XPath 1.0, while LValue of a TII can be only mapped to a Text node.

In WS-BPEL, <copy> operation is essentially a one-to-one replacment operation. That implies the from-spec and to-spec MUST select exactly one information item, which include the case of one TII. Also note that this restriction means that literal values can only contain either a TII or a single EII as its top level value..
----------------------------------

Adjust a bullet in section "Assignment" to fit the clarification of TII definition
FROM:
------------------------
a sequence of one or more character information items: this is mapped to a Text Node in the data model of XPath 1.0
------------------------
TO:
------------------------
a sequence of zero or more character information items: this is mapped to a Text Node or a String in the data model of XPath 1.0
------------------------

(C) Insert a new section on "Replacement Logic of Copy Operations"

----------------------------------
Replacement Logic of Copy Operations

Replacement Logic for WSDL Message Variables

When the from-spec and to-spec of  a <copy> operation select WSDL message variables, the  following replacement logic will be executed:
All existing message parts in the destination WSDL message variable (referred by the to-spec) will be removed and all existing message parts in the source WSDL message variable (referred by the from-spec) will be copied and added to destination WSDL message variable.


Replacement Table for XML Data Item:

When the from-spec and to-spec select one of three information items, the following replacement table defines the behavior of <copy> operation:

Src\Target
 EII
 AII
 TII
EII
RE
 RC
 RC
AII
 RC
 RC
 RC
TII
 RC
 RC
 RC


Definition
Note: Information items referenced by the to-spec MUST be a Lvalue. In XPath 1.0 data model, only Text Node can constitute a LValue of TII.


Using <copy> to initialize variables
When the destination selected by to-spec in <copy> is uninitialized, the destination variable or message part will be initialized first before executing the above replacement logic. Details of initialization are:

Handling Non-Infoset Data Item in <copy>

Simple type variables and values are allowed to manifested as non-Infoset data objects, such as, boolean, string, float defined in XPath 1.0. Also, some expressions can yield such a non-Infoset data object. For example:
        <from> number($order/amt) * 0.8 </from>

To consistently apply the replacement logic defined above, these non-Infoset data is handled as if they are Text Infoset Item (TII). The handled-as-TII logic is achieved through "to-string" data conversion, as TII resembles a string object.

To be more specific, when XPath 1.0 data model is used in WS-BPEL, the "string (object)" will be used to convert boolean or number object to String / TII. ( http://www.w3.org/TR/1999/REC-xpath-19991116#function-string )

Please note: the conversion is used to describe the expected result of <copy>. A WS-BPEL processor MAY skip the actual conversion for optimization if the result of <copy> remains the same and the conversion is redundant.

XML Namespace Preservation
During <copy> operation, the [in-scope namespaces] properties (similar to other XML Infoset Item properties) from the source MUST be preserved in the result at the destination. When variables are serialized into the XML-based text form, a WS-BPEL processor will make use of a namespace-aware XML infrastructure will add xmlns related attributes in XML-based text.

Given the replacement logic definition above, there are no true conflicts of XML namespace declaration between the source (i.e. selection result of from-spec) and destination (i.e. self-or-parent of the selection result of to-spec) in most of cases. XML namespace mechanism is flexible enough to handle those cases. For example:

<foo:bar xmlns:foo="http://foo.com">  
   <!-- this "foo:bar" element is pointed
        by to-spec as the destination of copy -->
   <foo:abc xmlns:foo="http://foo2.com" />
   <!-- this "foo:bar" element is pointed
        by to-spec as the destination of copy -->
</foo:bar>

However, there are some cases where a non-trivial conflict rises. For example:
v1:
<foo:bar xmlns:foo="http://foo.com" foo:attr="valueA" /> 

v2: (before copy)
<p:parent xmlns:p="http://foo.com" xmlns:foo="http://foo.some.com">
    <p:bar foo:attrX="valueY" />
</p:parent>

With the following copy operation, there would be conflict of prefix usage of "foo" used in foo:attr and foo:attrX, which are associated with "http://foo.com" and "http://foo.some.com":

<assign>
    <copy>
       <from>$v1</from>
       <to xmlns:p="http://foo.com">$v2/p:bar</to>
    <copy>
</assign>

To resolve conflict, the underlying namespace aware infrastructure is allowed to rename prefixes to non-conflicting ones if necessary. For example, after the copy operation is done, V2 may look like the following:

v2: (after copy)
<p:parent xmlns:p="http://foo.com" xmlns:foo="http://foo.some.com">
    <p:bar xmlns:foo2="http://foo.com" foo2:attr="valueA" />
</p:parent>

or

<p:parent xmlns:p="http://foo.com" xmlns:foo="http://foo.some.com">
    <p:bar p:attr="valueA" />
</p:parent>

Details of renaming prefixes are dependent on the underlying namespace aware infrastructure and they are outside of the scope of this specification. As the above example illustrates, there are usually more than one way to rename prefixes to handle this conflict to produce XML namespace consistent data.

When a schema-aware data model is used at runtime in WS-BPEL, similar prefix renaming mechanism may be used to handle namespace declaration conflicts in usage situation of QName values of attribute or text forms.

----------------------------------


In section "Assignment", change the <copy> syntax
FROM:
--------------------------
        <copy>
          from-spec
          to-spec
        </copy>
--------------------------
TO:
--------------------------
        <copy replaceElementName="yes|no"?>
          from-spec
          to-spec
        </copy>
--------------------------

Insert a paragraph before the paragraph starting with "An optional validate attribute can be used with the assign activity" as follows:
--------------------------
An optional replaceElementName attribute at the <copy> construct can be used to specify whether the element name of the destination (selected by to-spec) will be replaced by the element name of the soruce (selected by from-spec) during the copy operation. For details, please see section "Replacement Logic of Copy Operations".
--------------------------







END



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]