Author: vanto
Date: Mon Dec 31 10:41:12 2012
New Revision: 1427074

URL: http://svn.apache.org/viewvc?rev=1427074&view=rev
Log:
fix formatting.

Modified:
    
ode/site/trunk/content/extensions/extension-activities-extensible-assign-operations.mdtext
    ode/site/trunk/content/extensions/flexible-assigns.mdtext
    ode/site/trunk/content/extensions/headers-handling.mdtext
    ode/site/trunk/content/extensions/iterable-foreach.mdtext
    ode/site/trunk/content/extensions/restful-bpel-part-i.mdtext
    ode/site/trunk/content/extensions/restful-bpel-part-ii.mdtext

Modified: 
ode/site/trunk/content/extensions/extension-activities-extensible-assign-operations.mdtext
URL: 
http://svn.apache.org/viewvc/ode/site/trunk/content/extensions/extension-activities-extensible-assign-operations.mdtext?rev=1427074&r1=1427073&r2=1427074&view=diff
==============================================================================
--- 
ode/site/trunk/content/extensions/extension-activities-extensible-assign-operations.mdtext
 (original)
+++ 
ode/site/trunk/content/extensions/extension-activities-extensible-assign-operations.mdtext
 Mon Dec 31 10:41:12 2012
@@ -1,4 +1,4 @@
-Title: Extension Activities & Extensible Assign Operations
+Title: Extension Activities & Extensible Assign Operations
 Category: documentation
 
 ## BPEL Extensibility

Modified: ode/site/trunk/content/extensions/flexible-assigns.mdtext
URL: 
http://svn.apache.org/viewvc/ode/site/trunk/content/extensions/flexible-assigns.mdtext?rev=1427074&r1=1427073&r2=1427074&view=diff
==============================================================================
--- ode/site/trunk/content/extensions/flexible-assigns.mdtext (original)
+++ ode/site/trunk/content/extensions/flexible-assigns.mdtext Mon Dec 31 
10:41:12 2012
@@ -1,4 +1,6 @@
 Title: Flexible Assigns
+Category: documentation
+
 <a name="FlexibleAssigns-AutoCompleteCopyDestination(L-Value)"></a>
 ## Auto Complete Copy Destination (L-Value)
  
@@ -12,30 +14,30 @@ To override this default behavior, we in
 
 Formally, the grammar of the to-spec, for which auto-complete is enabled, may 
be defined in terms of these productions: 
 
-        PathExpr ::= ("/" RelativePathExpr?) | RelativePathExpr 
-        RelativePathExpr ::= ForwardStep (("/" ) ForwardStep)* 
-        ForwardStep ::= (ForwardAxis QName) | AbbrevForwardStep 
-        AbbrevForwardStep ::= "@"? QName 
-        ForwardAxis ::= ("child" "::") | ("attribute" "::") 
+    :::text
+    PathExpr ::= ("/" RelativePathExpr?) | RelativePathExpr 
+    RelativePathExpr ::= ForwardStep (("/" ) ForwardStep)* 
+    ForwardStep ::= (ForwardAxis QName) | AbbrevForwardStep 
+    AbbrevForwardStep ::= "@"? QName 
+    ForwardAxis ::= ("child" "::") | ("attribute" "::") 
 
 
 The example below illustrates the use of the insertMissingToData attribute. 
Let's say that the variable "response" is uninitialized. In that case, the 
first <copy> operation will fail, whereas the second one will succeed. 
 
-
-    
-        <copy> 
-            
<from>$request.requestMessageData/typeIndicators/types:indicatorTwo</from> 
-            <to>$response/typeIndicators/types:indicatorTwo</to> 
-        </copy> 
+    :::xml
+    <copy> 
+        
<from>$request.requestMessageData/typeIndicators/types:indicatorTwo</from> 
+        <to>$response/typeIndicators/types:indicatorTwo</to> 
+    </copy> 
     
-        <copy insertMissingToData="yes"> 
-            
<from>$request.requestMessageData/typeIndicators/types:indicatorTwo</from> 
-            <to>$response/typeIndicators/child::types:indicatorTwo</to> 
-         </copy> 
+    <copy insertMissingToData="yes"> 
+        
<from>$request.requestMessageData/typeIndicators/types:indicatorTwo</from> 
+        <to>$response/typeIndicators/child::types:indicatorTwo</to> 
+     </copy> 
 
 
-<a 
name="FlexibleAssigns-AddsupportfortheignoreMissingFromDataattributein<copy>"></a>
-## Add support for the ignoreMissingFromData attribute in <copy>
+<a 
name="FlexibleAssigns-AddsupportfortheignoreMissingFromDataattributeincopy"></a>
+## Add support for the ignoreMissingFromData attribute in `<copy>`
 
 The attached patch adds support for the following attributes in the BPEL 
assign activity's copy operation: 
 
@@ -45,7 +47,7 @@ The attached patch adds support for the 
 
 The informal syntax of the above attributes is shown below:
 
-
+    :::xml
     <copy ignoreMissingFromData="yes|no"? 
ignoreUninitializedFromVariable="yes|no"?> 
           from-spec to-spec 
     </copy> 

Modified: ode/site/trunk/content/extensions/headers-handling.mdtext
URL: 
http://svn.apache.org/viewvc/ode/site/trunk/content/extensions/headers-handling.mdtext?rev=1427074&r1=1427073&r2=1427074&view=diff
==============================================================================
--- ode/site/trunk/content/extensions/headers-handling.mdtext (original)
+++ ode/site/trunk/content/extensions/headers-handling.mdtext Mon Dec 31 
10:41:12 2012
@@ -1,4 +1,7 @@
 Title: Headers Handling
+Category: documentation
+
+## Overview
 There are several situations where one would want to access headers form the 
wire format in their BPEL process. It could be to assign them to another 
message and pass them around or to execute some business logic that's 
header-dependent (often a bad idea but sometimes there's no choice). ODE 
supports the manipulation of wire format headers in two different ways.
  
 <a name="HeadersHandling-HeadersasAbstractMessageParts"></a>

Modified: ode/site/trunk/content/extensions/iterable-foreach.mdtext
URL: 
http://svn.apache.org/viewvc/ode/site/trunk/content/extensions/iterable-foreach.mdtext?rev=1427074&r1=1427073&r2=1427074&view=diff
==============================================================================
--- ode/site/trunk/content/extensions/iterable-foreach.mdtext (original)
+++ ode/site/trunk/content/extensions/iterable-foreach.mdtext Mon Dec 31 
10:41:12 2012
@@ -1,4 +1,7 @@
 Title: Iterable ForEach
+Category: documentation
+
+## Overview
 This extension simplifies a common usage pattern in which forEach is used to 
iterate over a selected sequence of nodes.
  
 The common use case involves selecting a sequence of nodes, storing it in a 
scope variable, and using forEach to iterate over that sequence, using the 
current counter value to extract and operate on the indexed value from the 
sequence.  This extension captures the pattern in a form that's easier to 
author and debug, by replacing counter with iterator and eliminating the use of 
temporary variables.
@@ -7,10 +10,9 @@ The common use case involves selecting a
 <a name="IterableForEach-ProcessingMultipleBranches-ForEach"></a>
 ## Processing Multiple Branches - ForEach
 
-The <forEach> activity will execute its contained <scope> activity exactly M 
times where M is the number of items in the <sequenceValue>.
-
+The `<forEach>` activity will execute its contained <scope> activity exactly M 
times where M is the number of items in the <sequenceValue>.
 
-    
+    :::xml
     <forEach rangeName="BPELVariableName" parallel="yes|no"
        standard-attributes>
        standard-elements

Modified: ode/site/trunk/content/extensions/restful-bpel-part-i.mdtext
URL: 
http://svn.apache.org/viewvc/ode/site/trunk/content/extensions/restful-bpel-part-i.mdtext?rev=1427074&r1=1427073&r2=1427074&view=diff
==============================================================================
--- ode/site/trunk/content/extensions/restful-bpel-part-i.mdtext (original)
+++ ode/site/trunk/content/extensions/restful-bpel-part-i.mdtext Mon Dec 31 
10:41:12 2012
@@ -1,4 +1,8 @@
 Title: RESTful BPEL, Part I
+Category: documentation
+
+## RESTful BPEL (I)
+
 <div class="alert alert-warning">
     This feature is not yet implemented in ODE.  This is a proposal and is 
subject to change based on feedback, implementation experience, etc.
 </div>

Modified: ode/site/trunk/content/extensions/restful-bpel-part-ii.mdtext
URL: 
http://svn.apache.org/viewvc/ode/site/trunk/content/extensions/restful-bpel-part-ii.mdtext?rev=1427074&r1=1427073&r2=1427074&view=diff
==============================================================================
--- ode/site/trunk/content/extensions/restful-bpel-part-ii.mdtext (original)
+++ ode/site/trunk/content/extensions/restful-bpel-part-ii.mdtext Mon Dec 31 
10:41:12 2012
@@ -1,4 +1,7 @@
 Title: RESTful BPEL, Part II
+Category: documentation
+
+## RESTful BPEL (II)
 <div class="alert alert-warning">
     This feature is not yet implemented in ODE.  This is a proposal subject to 
feedback, implementation experience, etc.
 </div>
@@ -24,7 +27,7 @@ The above deal specifically with resourc
 <a name="RESTfulBPEL,PartII-Resources"></a>
 ### Resources
 
-Resources are declared in a scope, and a scope may declare any number of 
resources. A resource declaration consists of two properties, the resource 
*name*, which we use to reference the resource, and a relative *path* that 
denotes the relationship between this resource and other resources. Once 
instantiated, the value of the resource is an absolute URL.
+Resources are declared in a scope, and a scope may declare any number of 
resources. A resource declaration consists of two properties, the resource 
**name**, which we use to reference the resource, and a relative **path** that 
denotes the relationship between this resource and other resources. Once 
instantiated, the value of the resource is an absolute URL.
 
 The process can use resources in two ways. It can reference a resource for the 
purpose of receiving requests on that resource or a member of the collection 
denoted by the resource. It can also access the value of the resource (URL), 
for example, to send it as part of a message.
 
@@ -36,13 +39,13 @@ A resource that specifies no path (or th
 <a name="RESTfulBPEL,PartII-Recievingrequests"></a>
 ### Recieving requests
 
-To expose themselves as resources, the receive activity and event handler 
introduce four new properties. The *method* property specifies the HTTP method 
to accept, and the semantics of each HTTP method are described below. The 
*resource* property references a resource declaration available in the scope.
+To expose themselves as resources, the receive activity and event handler 
introduce four new properties. The **method** property specifies the HTTP 
method to accept, and the semantics of each HTTP method are described below. 
The **resource** property references a resource declaration available in the 
scope.
 
-The *instantiateResource* property is true if the resource is instantiated by 
the receive activity or event handler, and false if the resource must be 
instantiated before the activity executes. This property can only be set to 
true when using the POST method, and is always true for the instantiating 
activity of the process.
+The **instantiateResource** property is true if the resource is instantiated 
by the receive activity or event handler, and false if the resource must be 
instantiated before the activity executes. This property can only be set to 
true when using the POST method, and is always true for the instantiating 
activity of the process.
 
 When instantiateResource is false, the resource is instantiated first and the 
activity receives requests on that URL. When instantiateResource is true, the 
resource value is calculated and the activity receives requests on that URL. 
Once received, the resource is instantiated by appending a unique identifier to 
that URL. For example, the receive activity listens on the URL /foos, and upon 
receipt instantiates the resource to the URL /foos/123. In addition, the 
corresponding reply activity will set the status code to 201 (Created) and set 
the Location header to the resource URL.
 
-The *resourceIdentity* activity names a variable that will be set to the 
member identity when receiving requests on behalf of a collection resource. 
When used in event handlers, the variable is implicitly defined in the implicit 
scope of the event handler and has the type xsd:string.
+The **resourceIdentity** activity names a variable that will be set to the 
member identity when receiving requests on behalf of a collection resource. 
When used in event handlers, the variable is implicitly defined in the implicit 
scope of the event handler and has the type xsd:string.
 
 For example, if the resource is /foos/123/bars and the resourceIdentity is set 
to bar, then the activity will receive requests on the URL 
/foos/123/bars/\{bar\}, and the last part of the request URL path (the member 
identity \{bar\}) is assigned to the value of the variable bar.
 
@@ -91,5 +94,5 @@ The reply activity is matched to the cor
 Both receive and reply activities have access to an implicit message part 
called bodythat contains the internal representation of the document entity. 
Receive activities have access to an implicit message part called params, 
instantiated from the query string parameters. The XML representation of this 
part consists of the element Parameters, which maps query string parameters as 
follows:
 
 * foo -- Maps to the element foo.
-* foo\[bar\](bar\.html) -- Maps to the element bar contained in the parent 
element foo.
-* foo\[\](\.html) -- Each value is mapped to an element called foo in the 
parent element foos.
+* foo\[bar\] -- Maps to the element bar contained in the parent element foo.
+* foo\[\] -- Each value is mapped to an element called foo in the parent 
element foos.


Reply via email to