Proposal from Gary Brown:

http://lists.w3.org/Archives/Public/public-ws-chor/2005Mar/0013.html

Following on from Tony's ideas:

List/Array Access/Update issue

Date: 9th March 2005



Accessing a list or array

This can be achieved using existing XPath expression support. The CDL
'getVariable' function will return the value associated with a variable and
optionally a component within the XML document represented by the variable. It
would then be possible for the XPath expression to perform further evaluation on
the returned result.

Alternatively the list accessor could be placed in the XPath expression supplied
as a parameter to the 'getVariable' function.

For example, if we have a variable called 'doc' which contains the XML data from
Tony's previous example, then

variable 'doc' will contain:

    <listA>
        <listItem>1</listItem>
        <listItem>2</listItem>
        <listItem>4</listItem>
        <listItem>8</listItem>
    </listA>

If we also have a variable 'index' that is acting as an index value, so is of
type xs:integer, then the following Xpath expression would be used to access the
list element associated with the current index value,

cdl:getVariable('doc', '', "/listA/listItem[cdl:getVariable('index','','','')]", '')

Alternatively, we could move the list accessing expression outside the function:

cdl:getVariable('doc','')/listA/listItem[cdl:getVariable('index','','')]

This may be a better approach than embedding the XPath expression inside the
'getVariable' function, which avoids nested functions. It may be even better to
be able to reference CDL variables natively within the XPath expression,
although this would not cater for multi-part messages - and other
'isVariableAvailable' function would still be required.



Modifying a list or array

I don't think it is appropriate to add functions to XPath that modify the
document being queried, as this may have unknown consequences on the remainder
of the xpath evaluation.

My preference would be to use XPath expressions to identify the context for the
modification being performed, and then have specific activities to perform the
modification.

One possibility would be to change the current assign/copy construct, so that
copy would be a 'replace' operator, while 'insert'/'delete'/'append' operators
could be used for list manipulation.

For example,

<update> <!-- instead of 'assign' -->
    <copy target="cdl:getVariable('newNode')" expression="
'<listItem>16</listItem>' " />
    <append context="cdl:getVariable('doc')/listA"
expression="cdl:getVariable('newNode')" />
    <delete expression="cdl:getVariable('doc')/listA/listItem[2]" />
</update>

The 'insert' could be the same syntax as the append, with the addition of a
'position' attribute to indicate the insertion point.

If it is considered necessary to separate the variable from the context node
within the variable's document, then that could be easily achieved. For example,

<append variable="cdl:getVariable('doc')" context="/listA"
expression="cdl:getVariable('newNode')" />

NOTE: To support concurrent update of any information (but especially the
lists), within a choreography, we should stipulate that the 'update' activity is
atomic and isolated.

PROPOSAL TO CLOSE WON'T FIX and add text to primer

Basis:

To properly modify information (lists/arrays/xml documents) in concurrent threads requires a level of 
isolation/synchronization, and CDL only provides a coarse mechanism for this - so would prefer to 
leave these modifications for ***silentActions***, which can then implement any 
necessary synchronization.

We should not really be adding further activities that make this a more turing complete language.

Thus silentActions can be used as a suitable silent mechanism for accessing and modifying lists and 
arrays and therefore we do not need explicit support in WS-CDL to do this. 

The primer should include an example of how this might be done using WS-CDL, silentActions and a 
suitable end point language.

-DONE BY SRT

Changed QA Contact to steve from martin as steve is main author of primer and this has been 
reassigned as a primer issue