overview

2 files changed, 94 insertions, 76 deletions

diff --git a/plugins/org.eclipse.emf.cdo.doc/html/Overview.html b/plugins/org.eclipse.emf.cdo.doc/html/Overview.html
index 5153b6cdc5..3d09fbb5e4 100644
--- a/plugins/org.eclipse.emf.cdo.doc/html/Overview.html
+++ b/plugins/org.eclipse.emf.cdo.doc/html/Overview.html
@@ -40,62 +40,71 @@ function windowTitle()
 <h2><a name="Functionality"/>1&nbsp;&nbsp;Functionality</h2>
 <p>
  The main functionality of CDO can be summarized as follows:
- <ul>
- <li><b>Persistence</b> of your models in all kinds of database backends like major relational databases or NoSQL
+ <dl>
+ <dt><b>Persistence</b>
+ <dd>Persistence of your models in all kinds of database backends like major relational databases or NoSQL
  databases. CDO keeps your application code free of vendor specific data access code and eases transitions between
  the supported backend types.
  <p>
- <li><b>Multi user access</b> to your models is supported through the notion of repository sessions. The physical
- transport of sessions is pluggable and repositories can be configured to require secure authentication of users.
- Various authorization policies can be established programmatically.
- <p>
- <li><b>Transactional access</b> to your models with ACID properties is provided by optimistic and/or pessimistic
- locking on a per object granule. Transactions support multiple savepoints that changes can be rolled back to.
- Pessimistic locks can be acquired separately for read access, write access and the option to reserve write access
- in the future. All kinds of locks can optionally be turned into long lasting locks that survive repository
- restarts. Transactional modification of models in multiple repositories is provided through the notion of XA
- transactions with a two phase commit protocol.
- <p>
- <li><b>Transparent temporality</b> is available through audit views, a special kind of read only transactions that
- provide you with a consistent model object graph exactly in the state it has been at a point in the past. Depending
- on the chosen backend type the storage of the audit data can lead to considerable increase of database sizes in
- time. Therefore it can be configured per repository.
- <p>
- <li><b>Parallel evolution</b> of the object graph stored in a repository through the concept of branches similar to
- source code management systems like Subversion or Git. Comparisons or merges between any two branch points are
- supported through sophisticated APIs, as well as the reconstruction of committed change sets or old states of
- single objects.
- <p>
- <li><b>Scalability</b>, the ability to store and access models of arbitrary size, is transparently achieved by
- loading single objects on demand and caching them <i>softly</i> in your application. That implies that objects that
- are no longer referenced by the application are automatically garbage collected when memory contention occurs. Lazy
+ <dt><b>Multi User Access</b>
+ <dd>Multi user access to your models is supported through the notion of repository sessions. The physical transport
+ of sessions is pluggable and repositories can be configured to require secure authentication of users. Various
+ authorization policies can be established programmatically.
+ <p>
+ <dt><b>Transactional Access</b>
+ <dd>Transactional access to your models with ACID properties is provided by optimistic and/or pessimistic locking
+ on a per object granule. Transactions support multiple savepoints that changes can be rolled back to. Pessimistic
+ locks can be acquired separately for read access, write access and the option to reserve write access in the
+ future. All kinds of locks can optionally be turned into long lasting locks that survive repository restarts.
+ Transactional modification of models in multiple repositories is provided through the notion of XA transactions
+ with a two phase commit protocol.
+ <p>
+ <dt><b>Transparent Temporality</b>
+ <dd>Transparent temporality is available through audit views, a special kind of read only transactions that provide
+ you with a consistent model object graph exactly in the state it has been at a point in the past. Depending on the
+ chosen backend type the storage of the audit data can lead to considerable increase of database sizes in time.
+ Therefore it can be configured per repository.
+ <p>
+ <dt><b>Parallel Evolution</b>
+ <dd>Parallel evolution of the object graph stored in a repository through the concept of branches similar to source
+ code management systems like Subversion or Git. Comparisons or merges between any two branch points are supported
+ through sophisticated APIs, as well as the reconstruction of committed change sets or old states of single objects.
+ <p>
+ <dt><b>Scalability</b>
+ <dd>Scalability, the ability to store and access models of arbitrary size, is transparently achieved by loading
+ single objects on demand and caching them <i>softly</i> in your application. That implies that objects that are no
+ longer referenced by the application are automatically garbage collected when memory contention occurs. Lazy
  loading is accompanied by various prefetching strategies, including the monitoring of the object graph's
  <i>usage</i> and the calculation of fetch rules that are optimal for the current usage patterns. The scalability of
  EMF applications can be further increased by leveraging CDO constructs such as remote cross referencing or
  optimized content adapters.
  <p>
- <li><b>Thread safety</b> ensures that multiple threads of your application can access and modify the object graph
- without worrying about the synchronization details. This is possible and cheap because multiple transactions can be
- opened from within a single session and they all share the same object data until one of them modifies the graph.
- Possible commit conflicts can be handled in the same way as if they were conflicts between different sessions.
+ <dt><b>Thread Safety</b>
+ <dd>Thread safety ensures that multiple threads of your application can access and modify the object graph without
+ worrying about the synchronization details. This is possible and cheap because multiple transactions can be opened
+ from within a single session and they all share the same object data until one of them modifies the graph. Possible
+ commit conflicts can be handled in the same way as if they were conflicts between different sessions.
  <p>
- <li><b>Collaboration</b> on models with CDO is a snap because an application can opt in to be notified about remote
+ <dt><b>Collaboration</b>
+ <dd>Collaboration on models with CDO is a snap because an application can opt in to be notified about remote
  changes to the object graph. By default your local object graph transparently changes when it has changed remotely.
  With configurable change subscription policies you can fine tune the characteristics of your <i>distributed shared
  model</i> so that all users enjoy the impression to collaborate on a single instance of an object graph. The level
  of collaboration can be further increased by plugging custom collaboration handlers into the asynchronous CDO
  protocol.
  <p>
- <li><b>Data integrity</b> can be ensured by enabling optional commit checks in the repository server such as
- referential integrity checks and containment cycle checks, as well as custom checks implemented by write access
- handlers.
+ <dt><b>Data Integrity</b>
+ <dd>Data integrity can be ensured by enabling optional commit checks in the repository server such as referential
+ integrity checks and containment cycle checks, as well as custom checks implemented by write access handlers.
  <p>
- <li><b>Fault tolerance</b> on multiple levels, namely the setup of fail-over clusters of replicating repositories
- under the control of a fail-over monitor, as well as the usage of a number of special session types such as
- fail-over or reconnecting sessions that allow applications to hold on their copy of the object graph even though
- the physical repository connection has broken down or changed to a different fail-over participant.
+ <dt><b>Fault Tolerance</b>
+ <dd>Fault tolerance on multiple levels, namely the setup of fail-over clusters of replicating repositories under
+ the control of a fail-over monitor, as well as the usage of a number of special session types such as fail-over or
+ reconnecting sessions that allow applications to hold on their copy of the object graph even though the physical
+ repository connection has broken down or changed to a different fail-over participant.
  <p>
- <li><b>Offline work</b> with your models is supported by two different mechanisms:
+ <dt><b>Offline Work</b>
+ <dd>Offline work with your models is supported by two different mechanisms:
  <ul>
  <li>One way is to create a <b>clone</b> of a complete remote repository, including all history of all branches.
  Such a clone is continuously synchronized with its remote master and can either act as an embedded repository to
@@ -108,7 +117,7 @@ function windowTitle()
  concurrent transactions on the local checkout. In addition it supports most remote functionality that is known from
  source code management systems such as update, merge, compare, revert and check in.
  </ul>
- </ul>
+ </dl>
 
 <h2><a name="Architecture"/>2&nbsp;&nbsp;Architecture</h2>
 <p>
diff --git a/plugins/org.eclipse.emf.cdo.doc/src/org/eclipse/emf/cdo/doc/Overview.java b/plugins/org.eclipse.emf.cdo.doc/src/org/eclipse/emf/cdo/doc/Overview.java
index 9f64b086b7..1087746266 100644
--- a/plugins/org.eclipse.emf.cdo.doc/src/org/eclipse/emf/cdo/doc/Overview.java
+++ b/plugins/org.eclipse.emf.cdo.doc/src/org/eclipse/emf/cdo/doc/Overview.java
@@ -33,62 +33,71 @@ public class Overview
    * Functionality

    * <p>

    * The main functionality of CDO can be summarized as follows:

-   * <ul>

-   * <li><b>Persistence</b> of your models in all kinds of database backends like major relational databases or NoSQL

+   * <dl>

+   * <dt><b>Persistence</b>

+   * <dd>Persistence of your models in all kinds of database backends like major relational databases or NoSQL

    * databases. CDO keeps your application code free of vendor specific data access code and eases transitions between

    * the supported backend types.

    * <p>

-   * <li><b>Multi user access</b> to your models is supported through the notion of repository sessions. The physical

-   * transport of sessions is pluggable and repositories can be configured to require secure authentication of users.

-   * Various authorization policies can be established programmatically.

+   * <dt><b>Multi User Access</b>

+   * <dd>Multi user access to your models is supported through the notion of repository sessions. The physical transport

+   * of sessions is pluggable and repositories can be configured to require secure authentication of users. Various

+   * authorization policies can be established programmatically.

    * <p>

-   * <li><b>Transactional access</b> to your models with ACID properties is provided by optimistic and/or pessimistic

-   * locking on a per object granule. Transactions support multiple savepoints that changes can be rolled back to.

-   * Pessimistic locks can be acquired separately for read access, write access and the option to reserve write access

-   * in the future. All kinds of locks can optionally be turned into long lasting locks that survive repository

-   * restarts. Transactional modification of models in multiple repositories is provided through the notion of XA

-   * transactions with a two phase commit protocol.

+   * <dt><b>Transactional Access</b>

+   * <dd>Transactional access to your models with ACID properties is provided by optimistic and/or pessimistic locking

+   * on a per object granule. Transactions support multiple savepoints that changes can be rolled back to. Pessimistic

+   * locks can be acquired separately for read access, write access and the option to reserve write access in the

+   * future. All kinds of locks can optionally be turned into long lasting locks that survive repository restarts.

+   * Transactional modification of models in multiple repositories is provided through the notion of XA transactions

+   * with a two phase commit protocol.

    * <p>

-   * <li><b>Transparent temporality</b> is available through audit views, a special kind of read only transactions that

-   * provide you with a consistent model object graph exactly in the state it has been at a point in the past. Depending

-   * on the chosen backend type the storage of the audit data can lead to considerable increase of database sizes in

-   * time. Therefore it can be configured per repository.

+   * <dt><b>Transparent Temporality</b>

+   * <dd>Transparent temporality is available through audit views, a special kind of read only transactions that provide

+   * you with a consistent model object graph exactly in the state it has been at a point in the past. Depending on the

+   * chosen backend type the storage of the audit data can lead to considerable increase of database sizes in time.

+   * Therefore it can be configured per repository.

    * <p>

-   * <li><b>Parallel evolution</b> of the object graph stored in a repository through the concept of branches similar to

-   * source code management systems like Subversion or Git. Comparisons or merges between any two branch points are

-   * supported through sophisticated APIs, as well as the reconstruction of committed change sets or old states of

-   * single objects.

+   * <dt><b>Parallel Evolution</b>

+   * <dd>Parallel evolution of the object graph stored in a repository through the concept of branches similar to source

+   * code management systems like Subversion or Git. Comparisons or merges between any two branch points are supported

+   * through sophisticated APIs, as well as the reconstruction of committed change sets or old states of single objects.

    * <p>

-   * <li><b>Scalability</b>, the ability to store and access models of arbitrary size, is transparently achieved by

-   * loading single objects on demand and caching them <i>softly</i> in your application. That implies that objects that

-   * are no longer referenced by the application are automatically garbage collected when memory contention occurs. Lazy

+   * <dt><b>Scalability</b>

+   * <dd>Scalability, the ability to store and access models of arbitrary size, is transparently achieved by loading

+   * single objects on demand and caching them <i>softly</i> in your application. That implies that objects that are no

+   * longer referenced by the application are automatically garbage collected when memory contention occurs. Lazy

    * loading is accompanied by various prefetching strategies, including the monitoring of the object graph's

    * <i>usage</i> and the calculation of fetch rules that are optimal for the current usage patterns. The scalability of

    * EMF applications can be further increased by leveraging CDO constructs such as remote cross referencing or

    * optimized content adapters.

    * <p>

-   * <li><b>Thread safety</b> ensures that multiple threads of your application can access and modify the object graph

-   * without worrying about the synchronization details. This is possible and cheap because multiple transactions can be

-   * opened from within a single session and they all share the same object data until one of them modifies the graph.

-   * Possible commit conflicts can be handled in the same way as if they were conflicts between different sessions.

+   * <dt><b>Thread Safety</b>

+   * <dd>Thread safety ensures that multiple threads of your application can access and modify the object graph without

+   * worrying about the synchronization details. This is possible and cheap because multiple transactions can be opened

+   * from within a single session and they all share the same object data until one of them modifies the graph. Possible

+   * commit conflicts can be handled in the same way as if they were conflicts between different sessions.

    * <p>

-   * <li><b>Collaboration</b> on models with CDO is a snap because an application can opt in to be notified about remote

+   * <dt><b>Collaboration</b>

+   * <dd>Collaboration on models with CDO is a snap because an application can opt in to be notified about remote

    * changes to the object graph. By default your local object graph transparently changes when it has changed remotely.

    * With configurable change subscription policies you can fine tune the characteristics of your <i>distributed shared

    * model</i> so that all users enjoy the impression to collaborate on a single instance of an object graph. The level

    * of collaboration can be further increased by plugging custom collaboration handlers into the asynchronous CDO

    * protocol.

    * <p>

-   * <li><b>Data integrity</b> can be ensured by enabling optional commit checks in the repository server such as

-   * referential integrity checks and containment cycle checks, as well as custom checks implemented by write access

-   * handlers.

+   * <dt><b>Data Integrity</b>

+   * <dd>Data integrity can be ensured by enabling optional commit checks in the repository server such as referential

+   * integrity checks and containment cycle checks, as well as custom checks implemented by write access handlers.

    * <p>

-   * <li><b>Fault tolerance</b> on multiple levels, namely the setup of fail-over clusters of replicating repositories

-   * under the control of a fail-over monitor, as well as the usage of a number of special session types such as

-   * fail-over or reconnecting sessions that allow applications to hold on their copy of the object graph even though

-   * the physical repository connection has broken down or changed to a different fail-over participant.

+   * <dt><b>Fault Tolerance</b>

+   * <dd>Fault tolerance on multiple levels, namely the setup of fail-over clusters of replicating repositories under

+   * the control of a fail-over monitor, as well as the usage of a number of special session types such as fail-over or

+   * reconnecting sessions that allow applications to hold on their copy of the object graph even though the physical

+   * repository connection has broken down or changed to a different fail-over participant.

    * <p>

-   * <li><b>Offline work</b> with your models is supported by two different mechanisms:

+   * <dt><b>Offline Work</b>

+   * <dd>Offline work with your models is supported by two different mechanisms:

    * <ul>

    * <li>One way is to create a <b>clone</b> of a complete remote repository, including all history of all branches.

    * Such a clone is continuously synchronized with its remote master and can either act as an embedded repository to

@@ -101,7 +110,7 @@ public class Overview
    * concurrent transactions on the local checkout. In addition it supports most remote functionality that is known from

    * source code management systems such as update, merge, compare, revert and check in.

    * </ul>

-   * </ul>

+   * </dl>

    */

   public class Functionality

   {