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: Proposal for container node to simplify XML variables and messageparts


This is a bit over-due, but I hope we can finally discuss it 
face-to-face, and get some resolution. The proposal is to support XML 
varialables and message types based on a notion that exists in XPath, 
XQuery and DOM that does not require the complexity of adhering to the 
strict info-set model.

Problem:
--------

1. We want to support variables values and message parts that can be 
elements, simple types and complex types, with as little complexity to 
the spec as possible.
2. We want to support existing specifications and implementations 
without deviation.
3. We want expressions and assignments to be human readable and intuitive.


Solution:
---------

We define a 'container node' (and later on argue exactly what to call 
it) that has the following properties:
- It's a type of XML node
- It has no parent node, i.e. the container node is always a root node
- It has any number of child nodes, zero child nodes are allowed (e.g. 
an empty string)
- Child nodes may be any valid node types, e.g. element, attribute, 
text, comment, etc
- The order of child nodes is preserved, in order to honor XPath 
document order

We declare that each XML variable or message part is a container node, 
where the value of that variable or message part are the child nodes of 
the container node. More specifically:
- For a variable/message part that is an element, the only child node of 
the container node is an element of that type
- For a variable/message part that is a simple type, the only child node 
of the container node is a character data node with a text value of that 
type
- For a variable/message part that is a complex type, the child nodes of 
the container nodes are the elements allowed in the complex type, based 
on the content model of the complex type

To handle assignments and expressions, we declare that:
- When XML content is assigned to a variable or message part, the XML 
content (character data, element, sequence of elements) becomes the 
child nodes of the container node[*]
- When the variable or message part is referenced in an expression 
(XPath or XQuery), the result of that reference is a nodeset with the 
child nodes of the container node
- When the variable or message part is used as the context for an 
expression (XPath or XQuery), the container node is used as the context node


[*] In XPath this is just a matter of iterating over the returned 
nodeset, cloning each node and appending it as a child of the container 
node.


Examples
--------

Declare a variable of simple type string and assign the value 'hello 
world' to it:

<variable name="text" type="xsd:string"/>
<assign>
  <copy>
    <from>
      <literal>hello world</literal>
    </from>
    <to variable="text"/>
  </copy>
</assign>

Declare a variable that holds an element myElement and assign an element 
to it:

<variable name="element" element="ns:myElement"/>
<assign>
  <copy>
    <from>
      <literal><ns:myElement>hello world</ns:myElement></literal>
    </from>
    <to variable="element"/>
  </copy>
</assign>

Copy the text value from one variable to another:

<variable name="text2" type="xsd:string"/>
<assign>
  <copy>
    <from>$text</from>
    <to variable="text2"/>
  </copy>
</assign>

<variable name="text3" type="xsd:string"/>
<assign>
  <copy>
    <from>$element/text()</from>
    <to variable="text3"/>
  </copy>
</assign>

Copy an element from a complex type to an element variable:

<variable name="sequence" type="ns:myComplexType"/>
<variable name="element3" element="ns:myElement"/>
<assign>
  <copy>
    <from>$sequence/ns:myElement</from>
    <to variable="element3"/>
  </copy>
</assign>

Evaluate an expression using a context node:

<bpws:propertyAlias propertyName="tns:taxpayerNumber"
                    messageType="txmsg:taxpayerInfo" part="identification">
    <query>/txtyp:socialsecnumber</query>
</bpws:propertyAlias>

Note that '/txtyp:socialsecnumber', 'txtyp:socialsecnumber' and 
'./txtyp:socialsecnumber' are all valid and refer to the same child node.


Conformance
-----------

The XPath 1.0 specification defines a 'root node' that may be used as a 
context node or a node in a node-set. The XPath 1.0 specification makes 
no restriction on the root node that prevent us from using the container 
node as a root node. Any XPath 1.0 conformant implementation would 
support the container node.

The XPath 2.0 data model specification defines a 'document node' that 
may be used as a context node or any other place a node is returned. The 
container node has the same properties as an XPath 2.0 data model 
document node. Any XPath 2.0 or XQuery 1.0 conformant implementation 
would support the container node.

The DOM Level 1 specification defines a 'document fragment' node type. 
The container node has the same properties as a DOM document fragment. 
An implementation that uses the DOM can use the DocumentFragment node to 
represent the container node, and to pass it to/from an XPath engine.

begin:vcard
fn:Assaf Arkin
n:Arkin;Assaf
org:Intalio
adr;dom:;;1000 Bridge Parkway Ste 210;Redwood City;CA;94065
email;internet:arkin@intalio.com
title:Chief Architect
tel;work:(650) 596-1800
x-mozilla-html:TRUE
url:http://www.intalio.com
version:2.1
end:vcard

S/MIME Cryptographic Signature



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