svn commit: r1426639 - /ode/site/trunk/content/ws-bpel-20-specification-compliance.mdtext

[va...@apache.org]

Author: vanto
Date: Fri Dec 28 21:27:24 2012
New Revision: 1426639

URL: http://svn.apache.org/viewvc?rev=1426639&view=rev
Log:
link cleanup.

Modified:
    ode/site/trunk/content/ws-bpel-20-specification-compliance.mdtext

Modified: ode/site/trunk/content/ws-bpel-20-specification-compliance.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/ws-bpel-20-specification-compliance.mdtext?rev=1426639&r1=1426638&r2=1426639&view=diff
==============================================================================
--- ode/site/trunk/content/ws-bpel-20-specification-compliance.mdtext (original)
+++ ode/site/trunk/content/ws-bpel-20-specification-compliance.mdtext Fri Dec 28 21:27:24 2012
@@ -44,7 +44,7 @@ The specification defines two standard f
 Finally, the `validate` attribute --- if present --- is ignored: ODE currently provides no variable validation.
 
 <a name="WS-BPEL2.0SpecificationCompliance-reply"></a>
-### <[reply](reply.html)>
+### <reply>
 The conformance issues with the `<reply>` activity mirror those of the `<receive>` activity as described above: the `<toPart>` syntax is not supported, and `variable` attributes must reference message-typed variables.
 
 <a name="WS-BPEL2.0SpecificationCompliance-invoke"></a>
@@ -64,39 +64,39 @@ ODE currently uses the `expressionLangua
 There are no other known divergences from the specification relating to the `<assign>` activity that would prevent the execution of valid BPEL assignments. ODE provides certain (non-standard) extensions to the `<assign>` activity that do not conform to the specification's requirements for assignment extensions. Consult the [reference page](assign.html) for the `<assign>` activity for further details regarding non-standard extensions.
 
 <a name="WS-BPEL2.0SpecificationCompliance-throw"></a>
-### <[throw](throw.html)>
+### <throw>
 The `<throw>` activity is fully compliant with the specification.
 
 <a name="WS-BPEL2.0SpecificationCompliance-exit"></a>
-### <[exit](exit.html)>
+### <exit>
 The `<exit>` activity is fully compliant with the specification.
 
 <a name="WS-BPEL2.0SpecificationCompliance-wait"></a>
-### <[wait](wait.html)>
+### <wait>
 The `<wait>` activity is fully compliant with the specification.
 
 <a name="WS-BPEL2.0SpecificationCompliance-empty"></a>
-### <[empty](empty.html)>
+### <empty>
 The `<empty>` activity is fully compliant with the specification.
 
 <a name="WS-BPEL2.0SpecificationCompliance-sequence"></a>
-### <[sequence](sequence.html)>
+### <sequence>
 The `<sequence>` activity is fully compliant with the specification.
 
 <a name="WS-BPEL2.0SpecificationCompliance-if"></a>
-### <[if](if.html)>
+### <if>
 The `<if>` activity is fully compliant with the specification.
 
 <a name="WS-BPEL2.0SpecificationCompliance-while"></a>
-### <[while](while.html)>
+### <while>
 The `<while>` activity is fully compliant with the specification.
 
 <a name="WS-BPEL2.0SpecificationCompliance-repeatUntil"></a>
-### <[repeatUntil](repeatuntil.html)>
+### <repeatUntil>
 The `<repeatUntil>` activity is fully compliant with the specification.
 
 <a name="WS-BPEL2.0SpecificationCompliance-forEach"></a>
-### <[forEach](foreach.html)>
+### <forEach>
 The `<forEach>` activity is fully compliant with the specification.  ODE supports both sequential and parallel for-each semantics.
 
 <a name="WS-BPEL2.0SpecificationCompliance-pick"></a>
@@ -104,11 +104,11 @@ The `<forEach>` activity is fully compli
 The <[pick](pick.html)> activity has the same issues as the <[receive](receive.html)> activity.
 
 <a name="WS-BPEL2.0SpecificationCompliance-flow`"></a>
-### <[flow](flow.html)>
+### <flow>
 The `<flow>` activity is fully compliant with the specification.
 
 <a name="WS-BPEL2.0SpecificationCompliance-scope"></a>
-### <[scope](scope.html)>
+### <scope>
 Isolated scopes are implemented in ODE's experimental branch (as of September 2007) and will be released in ODE 2.x.
 
 ODE v1.0/1.1 do not support isolated scopes nor do they support "exit on standard fault" semantics. Hence, a BPEL 2.0 process will be interpreted as if  any `isolated` and `exitOnStandardFault` attributes on `<scope>` elements did not exist.
@@ -118,11 +118,11 @@ ODE v1.0/1.1 do not support isolated sco
 The `<compensate>` activity is not compliant with the specification. In ODE, this activity has the same effect and syntax as `<compensateScope>`. In addition, the `scope` attribute may be used in place of the `target` attribute with the same effect; and  ODE expects one of these attributes must be specified.
 
 <a name="WS-BPEL2.0SpecificationCompliance-compensateScope"></a>
-### <[compensateScope](compensatescope.html)>
+### <compensateScope>
 The `<compensateScope>` activity is fully compliant with the specification.
 
 <a name="WS-BPEL2.0SpecificationCompliance-rethrow"></a>
-### <[rethrow](rethrow.html)>
+### <rethrow>
 The `<rethrow>` activity is fully compliant with the specification.
 
 <a name="WS-BPEL2.0SpecificationCompliance-validate"></a>
@@ -130,5 +130,5 @@ The `<rethrow>` activity is fully compli
 The `<validate>` activity is  _not_  implemented by ODE. Processescontaining such activities will cause a compilation failure.
 
 <a name="WS-BPEL2.0SpecificationCompliance-extensionActivity"></a>
-### <[extensionActivity](extensionactivity.html)>
+### <extensionActivity>
 Activity extension is not supported in ODE. There is an implementation in the ODE experimental branch.