anchor.diff:  public class TempleOfDoom {
   
     public static void main(String[] args) {
  -    CdoManagerFactory cmf = Cdo.createCdoManagerFactory("movies");
  -    CdoManager cm = cmf.createCdoManager();
  -    cm.currentTransaction.begin();
  -    Actor harrison = cm.create(Actor.class);
  +    XOManagerFactory xmf = XO.createXOManagerFactory("movies");
  +    XOManager xm = xmf.createXOManager();
  +    xm.currentTransaction.begin();
  +    Actor harrison = xm.create(Actor.class);
       harrison.setName("Harrison Ford");
   
       // Create Steven as composite object using more than one role
  -    CompositeObject steven = cm.create(Director.class, Actor.class);
  +    CompositeObject steven = xm.create(Director.class, Actor.class);
   
       // Use Steven in the role of an actor
       steven.as(Actor.class).setName("Steven Spielberg");
   
  -    Movie temple = cm.create(Movie.class);
  +    Movie temple = xm.create(Movie.class);
       temple.setTitle("Temple Of Doom");
   
       // Use Steven in the role of a director as the "director" property of the type Movie requires it
  
positive.code: public class RaidersOfTheLostArk {
  
    public static void main(String[] args) {
      // Bootstrap CDO, a file META-INF/cdo.xml is expected on the classpath
      CdoManagerFactory cmf = Cdo.createCdoManagerFactory("movies");
  
      // Obtain a CdoManager (i.e. a connection to the datastore)
      CdoManager cm = cmf.createCdoManager();
  
      // Begin a transaction
      cm.currentTransaction.begin();
  
      // Create a data object representing an actor
      Actor harrison = cm.create(Actor.class);
      harrison.setName("Harrison Ford");
  
      // Create a data object representing a director
      Directory steven = cm.create(Director.class);
      steven.setName("Steven Spielberg");
  
      // Create a data object representing a movie
      Movie raiders = cm.create(Movie.class);
      raiders.setTitle("Raiders Of The Lost Ark");
  
      // Set the relations between all the created data objects
  
negative.code: eXtended Objects
  ================
  Dirk Mahler <dirk.mahler@buschmais.com>
  
  This document describes the core concepts of eXtended Objects.
  
  :numbered!:
  [abstract]
  eXtended Objects
  ----------------
  Modeling data objects for datastores (i.e. databases) in various domains often requires common properties
  (e.g. lastChangedBy, created, name, etc.) to be present in several data types. This is commonly solved by defining
  abstract base types representing a specific aspect or role and defining these properties here. Concrete data types may
  derive from these base types if the information is needed. This approach comes to its limits if more than one aspect
  shall be re-used in one POJO as multiple inheritance is not supported for classes in the Java language.
  
  eXtended Objects (XO) allows modeling types as interfaces by specifying the required accessor methods
  (i.e. getter and setter) and composing these types either statically or dynamically. The XO API uses well-known
  concepts from existing persistence APIs (e.g. JPA, JDO) but extends them with functionality which is enabled by using
  interfaces to define the data objects, e.g. type migration at runtime.
  The XO implementation itself is datastore-agnostic, i.e. it does not depend on specific datastore concepts like
  relational or graph databases, document stores etc. but allows using them. Datastore specific implementations can be
  provided by implementing the SPI (Service Provider Interface), the reference implementation is based on the
  graph database Neo4j.
  