fixed some markdown bits

README.md

@@ -6,60 +6,60 @@ engine and either evaluate rules or run various processes.
 
 By package:
 
-```rules```
+`rules`
 -----------
 
- - ```SimpleMatch```
-    - Knowledge Base: ```simple```
-    - Package(s): ```simple```
+ - `SimpleMatch`
+    - Knowledge Base: `simple`
+    - Package(s): `simple`
     - Description: A couple of simple examples of rule matching.
 
- - ```FactIntegritySingle```, ```FactIntegrityMultiple```
-    - Knowledge Base: ```integrity```
-    - Package(s): ```integrity```
+ - `FactIntegritySingle`, `FactIntegrityMultiple`
+    - Knowledge Base: `integrity`
+    - Package(s): `integrity`
     - Description: Shows how referential integrity must be used when working
       with multiple unrelated sets of facts.
 
- - ```AssertAndQueryFacts```
-    - Knowledge Base: ```awards```
-    - Package(s): ```facts```
+ - `AssertAndQueryFacts`
+    - Knowledge Base: `awards`
+    - Package(s): `facts`
     - Description: Shows how Drools queries can be used to retrieve facts that
       may not have existed prior to firing the rules.
 
- - ```AgendaGroupsWrongOrderLog```, ```AgendaGroupsRightOrderLog```
-    - Knowledge Base: ```agendaWrong```, ```agendaRight```
-    - Package(s): ```agenda.wrong```, ```agenda.right```
+ - `AgendaGroupsWrongOrderLog`, `AgendaGroupsRightOrderLog`
+    - Knowledge Base: `agendaWrong`, `agendaRight`
+    - Package(s): `agenda.wrong`, `agenda.right`
     - Description: Shows how using agenda groups can be used to stage rule
       evaluation. A nice example of an unsolvable infinite firing loop.
       Additionally, shows how global variables can be used to pass service
       objects, such as loggers, to your rule engine (and how to use them in
       rule consequences).
 
-```processes```
+`processes`
 ---------------
 
- - ```ProcessWithFacts```
-    - Knowledge Base: ```ruleflow```
-    - Package(s): ```ruleflow```
-    - Process(es): ```ruleflow.RulesRulesRules```
+ - `ProcessWithFacts`
+    - Knowledge Base: `ruleflow`
+    - Package(s): `ruleflow`
+    - Process(es): `ruleflow.RulesRulesRules`
     - Description: Inserts facts into working memory and starts a process
       without parameters. Shows that the facts are not visible to process
       tasks.
 
- - ```ProcessWithParams```
-    - Knowledge Base: ```ruleflow```
-    - Package(s): ```ruleflow```
-    - Process(es): ```ruleflow.RulesRulesRules```
+ - `ProcessWithParams`
+    - Knowledge Base: `ruleflow`
+    - Package(s): `ruleflow`
+    - Process(es): `ruleflow.RulesRulesRules`
     - Description: Starts a process with parameters instead of inserting facts.
       Check the Business Rule Tasks' I/O Parameter settings to see how to
       present those parameters to the rule engine. One shortcoming here is that
-      rules **insert** awards into working memory, so they still need to be
+      rules __insert__ awards into working memory, so they still need to be
       retrieved using a query.
 
- - ```ProcessWithParamsOnly```
-    - Knowledge Base: ```ruleflowParams```
-    - Package(s): ```ruleflow_params```
-    - Process(es): ```ruleflow.RulesRulesRules``` (different package!)
+ - `ProcessWithParamsOnly`
+    - Knowledge Base: `ruleflowParams`
+    - Package(s): `ruleflow_params`
+    - Process(es): `ruleflow.RulesRulesRules` (different package!)
     - Description: This time around, no facts are created by the rules,
       consequently the query comes up empty-handed. However, relationship
       between Customer and Award is established prior to starting the process,
@@ -67,76 +67,76 @@ By package:
       our integration code - thanks to pass-by-reference, any modifications to
       Award are visible in the main() method after returning.
 
- - ```ProcessWithListParams```
-    - Knowledge Base: ```ruleflowParams```
-    - Package(s): ```ruleflow_params```
-    - Process(es): ```ruleflow.RulesWithListParams```
+ - `ProcessWithListParams`
+    - Knowledge Base: `ruleflowParams`
+    - Package(s): `ruleflow_params`
+    - Process(es): `ruleflow.RulesWithListParams`
     - Description: Just here to show that wrapped parameters (such as a
-      ```List<Customer>```) do not match the rules. Facts must be presented
+      `List<Customer>`) do not match the rules. Facts must be presented
       individually for the matching patterns to be able to see them. The
       process was just modified to change parameter types and adjust I/O
       mappings for BR tasks. No other logic changes.
 
- - ```ProcessWithListSubProcess```
-    - Knowledge Base: ```ruleflowParams```
-    - Package(s): ```ruleflow_params```
-    - Process(es): ```ruleflow.RulesWithListSubProc```
+ - `ProcessWithListSubProcess`
+    - Knowledge Base: `ruleflowParams`
+    - Package(s): `ruleflow_params`
+    - Process(es): `ruleflow.RulesWithListSubProc`
     - Description: A working, albeit ugly, way of handling list parameters in
       processes. To present individual data objects to the working memory, two
-      parallel __multi-instance__ subprocesses had to be created, each with its
-      own ```List``` as the driver. The sub-processes then iterate over the
+      parallel _multi-instance_ subprocesses had to be created, each with its
+      own `List` as the driver. The sub-processes then iterate over the
       lists, and a single script task in each of the two is used to insert the
       facts into the working memory. Since there is the possibility that
       multiple customers have been passed in for processing, the
       congratulations task must also iterate over the list of awards and decide
-      whom to congratulate based on each award's state. Uses the ```kcontext```
+      whom to congratulate based on each award's state. Uses the `kcontext`
       implicit global variable in script tasks, and is hence non-portable.
 
-```use_rest```
+`use_rest`
 --------------
 
-All of the classes in this package use the ```serviceTasks``` knowledge base,
-which only makes the ```service_tasks``` Kie package available to the engines.
+All of the classes in this package use the `serviceTasks` knowledge base,
+which only makes the `service_tasks` Kie package available to the engines.
 
- - ```UseSimpleJavaBeanService```
-    - Process: ```servicetasks.JavaBeanServiceTask```
-    - Implementation: ```beans.GenerateCustomer```
+ - `UseSimpleJavaBeanService`
+    - Process: `servicetasks.JavaBeanServiceTask`
+    - Implementation: `beans.GenerateCustomer`
     - Description: Showcase a plain Java bean being used as a service task. No
       REST whatsoever.
 
- - ```UseRestEasyManualClient```
-    - Process: ```servicetasks.JavaRestClientServiceTask```
-    - Implementation: ```ws_client.CustomerServiceClient```
+ - `UseRestEasyManualClient`
+    - Process: `servicetasks.JavaRestClientServiceTask`
+    - Implementation: `ws_client.CustomerServiceClient`
     - Description: Uses a manual implementation of a REST client using RestEasy
-      ```Request```/```Response``` approach. Note how the service task does not
+      `Request`/`Response` approach. Note how the service task does not
       change, in principle, it is the implementation that makes the difference.
 
- - ```UseRestEasyProxyClient```
-    - Process: ```servicetasks.JavaRestProxyServiceTask```
-    - Implementation: ```ws_client.CustomerServiceProxy```
+ - `UseRestEasyProxyClient`
+    - Process: `servicetasks.JavaRestProxyServiceTask`
+    - Implementation: `ws_client.CustomerServiceProxy`
     - Description: Just a switch from manual implementation to a proxy-based
-      REST client, using the interface from the ```shared-data-model```
+      REST client, using the interface from the `shared-data-model`
       project. Much easier and safer.
 
- - ```UseRestServiceTask```
-    - Process: ```servicetasks.BpmnRestTask```
-    - Implementation: __internal__
+ - `UseRestServiceTask`
+    - Process: `servicetasks.BpmnRestTask`
+    - Implementation: _internal_
     - Description: Uses a custom WorkItemHandler to register an internal REST
       client which is then configured in a custom task in the process model
       itself. Remember how we had to manually modify the BPMN2 model to add a
-      ```taskName="Rest"``` attribute as the CodeReady tooling does not have a
+      `taskName="Rest"` attribute as the CodeReady tooling does not have a
       definition of a REST custom task, and regularly chokes on it, or else,
-      without the ```taskName``` attribute, the engine complains that the
+      without the `taskName` attribute, the engine complains that the
       custom task has no type and dies.
 
-__top-level package__
----------------------
+_top-level package_
+-------------------
 
-Just contains a single class, ```UseRemoteKieArtifact```, which loads a RHPAM
+Just contains a single class, `UseRemoteKieArtifact`, which loads a RHPAM
 project with GAV coordinates of
-```net.p0f.samples.rhpam-fuse-integration:pam-simple-process:1.0.0-SNAPSHOT```
-using a remote ```KieContainer```, and then just for the sake of the example,
-also creates a ```KieScanner``` which has the ability to reload that container
+`net.p0f.samples.rhpam-fuse-integration:pam-simple-process:1.0.0-SNAPSHOT`
+using a remote `KieContainer`, and then just for the sake of the example,
+also creates a `KieScanner` which has the ability to reload that container
 and update it to latest version in order for new sessions to be able to use the
 updated artifacts.