Each publication is autonomous and independent. Publications are stored in files.

There is no central database or repository for storing publications.

One publication must often be split over many files because one file would become too big to be handled by the DTP software, because files are loaded entirely into memory.

Original content data and publications visualizing this content are permanently separated.

Publications hold their content physically inside them. Therefore, any change to one side must be transferred to the other side. Automatic procedures are impossible.

Re-using data is impossible, only duplicating objects is possible, which thereafter have lost all connections to their templates.

A publication is a composition of several pre-defined and pre-designed inheritable objects stored in the object repository in the publishing database.

Everything is in a database. Publications can be as big as there is disk space. No realistic limits!

Publications and all their components are compilations of children of such inheritable objects, each keeping permanent access to their mother objects. Therefore, designing a publication really only means just selecting the objects to inherit from, rarely enhancing existing objects by creating new mothers by inheriting from an already existing mother.

Publications are stored in the publication database but without the content, which is stored in the content database(s), administrated by EleStore, unless data or frames are declared to be "frozen".

Content data is loaded from the database each time a page is loaded, shown, printed or exported.Any change to data on either side instantly affects the other side.

Making a new frame means creating a new independent frame on a page. In some systems frames can be stored as templates, which can be used to create new instances as copies of the templates. The new instances keep no connection to their template. Therefore, changing the template’s attributes has no influence on the objects, which were once created from it.

Layouts ar independent collections of independent frames. All changes must be applied to all frames. All frames are independent from one another.

Containers are unknown. Grouping is no substitute for containers.

Any new frame is either:
• another mother object, which inherits most of its attributes from one of the many existing objects in the ancestor genealogy overwriting only the few attributes in which it differs from its ancestor (mostly only the size)
• or a concrete object, i.e. a child of one of the mother objects, which is placed on a page and which inherits typically all of its attributes from its ancestor.

Layouts are built as multi-level hierarchies of container objects, where each container is the holder of logically connected data items.

Containers are essential building blocks aggregating logically connected frames. A page is the outermost container.

Each frame is an autonomous entity equipped with a full set of its own attributes. All such attributes must be applied to each frame. Every change will have to be done to every frame.

There are no interconnections or dependencies between frames beyond grouping, which is no substitute for containers. Containers are unknown.

Frames and all other visualization objects are created from a hierarchy of inheritable ancestor objects. On each inheritance level objects can have their own attributes overwriting any of the attributes inherited from ancestors.

All children objects permanently keep contact and have access to any of their ancestor objects avoiding any data redundancy. Like this highly re-usable object trees are created and used to build publications from them.

Positioning of frames is always relative to the page.

There are no containers, which could wrap several frames to a logical entity. Containers are unknown.

Any position change to any frame will not affect the positioning of (logically) related frames because there is no relation between the frames in their data.

Positioning dependencies of related frames are unknown, also because related frames are unknown.

Placing of frames is always relative to their container.

All frames are held by containers with the page frame being the outermost container. The container is the "universe"to all its members. The coordinate system used is always related to a container's top left corner.

Any change to a frame's size and/or position inside a container (could also be the page) will instantly affect all related frames, reposition successors and/or neighbors of the moved or changed frame.

There can be and mostly are strong relative and rule-based dependencies in the positioning of related frames.

Select manually all frames, which together form a logical unit, and group them to avoid accidental changes to their relative position. Then copy or move the group of frames.

Changing the position of a single frame will never affect the position of any other frame even if one logically depends on the other.

Logical dependencies are unknown.

Pick a container and move or copy it. All members of the container will remain inside it and keep their relative position inside their container "universe".

Repositioning of container members is never needed, although it can be applied if needed.

Multiple and flexible logical dependencies exist through containers and/or positioning rules.

A layout is typically a composition of independent frames, which together define a layout component for an article or a group of articles.

Containers are unknown.

Relative positioning of frames with respect to one another is unknown.

Frame sizes can be calculated when they are automatically generated but any later change to their content will not recalculate their size nor the size or positioning of their neighbors.

Layouts are composed from object modules and typically stored in the object repository to be re-used through inheritance (do once, re-use often). Concrete layouts on pages are always children of ancestor layouts inheriting most of their attributes. One can easily extend the standard object library of visualization components coming with ElePub.

Frames inside layout containers are typically positionioned relative to one another so that changing one container member affects all related other members. This typically creates layouts with strongly related members often having relative sizes and positions.

Differences and advantages:
• layouts are three dimensional container objects
• layouts are constructed from modular re-used components called mother objects
• layouts are containers holding frames, tables and other layouts
• a page is the outermost container capable of holding any number of multi-level depth containers each holding other containers or frames
• tables are a special kind of containers

Each frame physically holds its own data, which has been imported from the database.

Data has been taken from a database and copied into the frame. Therefore, frames only hold duplicates of the original database values, which have no permanent contact to the database.

Any change to the frame data or to the database data have to be ported into the other world by complex batch processes at best, typically by re-generating a whole page or chapter.

A frame visualizes the value in the database (not from the database). The datum on a page and in the database are absolutely identical.

The content is not inside the frame but it is loaded from the database whenever a page is loaded, shown, printed or exported. This is initiated by each individual frame, which typically only contains a link to the database but not the data itself (option).

Content is logically kept in the EleStore CMS or physically can be housed in your existing database(s). Therefore, any change to the frame value is really a change to the database value and any change to the database instantly changes the frame value on a page. Both are identical.

As an exception, frames can also hold their own data ("frozen") independent of the database, so that versions and frozen data states are supported. But even data frozen inside frames can be compared to the current database state and/or updated from the current database content.

Differences and advantages:
• frames visualize the real database content
• data in a frame is in the database not from the database, not a copy of the database item
• data can be frozen in frames
• frozen date can be compared against or updated from the database.

The database publishing application fully relies on one of the well known DTP software products and it would be useless without a DTP software.

The result of page generation is a DTP document (file). All further work is done inside the DTP software.

Some database publishing applications have their own data storage for templates and settings. But even then, both applications are only loosely coupled using different data formats.

ElePub is an autonomous and fully self-contained application, which does not need any DTP software. All work, changes, editing etc. is done in ElePub.

DTP software is only needed for color separation and, in very rare cases, for some "fine art"of typography.

ElePub can exported finished and complete pages to QuarkXpress, InDesign or Framemaker with no or very little work to be done there.

Additionally, EleStore offers a completely autonomous content management, which can be used fully self-contained or in close co-operation with your existing databases and file servers.

Database publishing applications automatically create DTP documents. Insofar they convert their own internal format to the one of the target DTP software.

Result is always a DTP document.

Conversion to DTP is absolutely unnecessary. For most publications and applications ElePub can do entirely without any DTP software.

ElePub fully mantles DTP objects and entire DTP documents. ElePub can import and exported finished and complete pages from and to QuarkXpress, InDesign or Framemaker. Typically, no or very little work to be done in the DTP software.

ElePub fully incorporates DTP data structures and uses them in several ways:
• Normally ElePub stores pages and documents in its own internal object format in the database and exports only the final document into DTP files for color separation.
• ElePub can read in existing DTP pages or entire documents and store them in its own object structures for modification and later re-use.
• ElePub is able to re-create previously imported DTP documents with changed content and/or format from its own object structures.

Changing content data or format on a page always happens inside the DTP software.

As a consequence any change must be re-imported into the original source database, which cannot be performed automatically by the DTP software itself. This requires a batch process, which must be started manually.

Changing data on an ElePub page changes this data in the database.

Both are the same entity with no difference between them except for the wanted formatting details, i.e. for the particular form of visualization used for a database datum on a particular page. This only affects the format (font type, size etc.), which is voluntarily stored separately from the content datum.

Page and database contain physically different data entities, which are only loosely coupled.

Aligning data between pages and database needs batch processes. Therefore, it is very hard and requires much discipline to keep DTP pages and sources data permanently aligned.

No alignment between pages and database is ever needed.

Page and database contain the same data items. Data on a page is really the data in the database, not a copy of the data from the database.

DTP page content and database data are physically and logically completely independent from one another.

Frame data is a copy of the database item. At best, the frame has a hidden link to the database datum for use by batch update processes.

Any change to the database must be exported to the DTP software by "simply"re-generating affected pages. All changes to these pages are lost, unless they are imported to the database. This requires a manually started batch process. This update process causes the problem that it might overwrite changes done to the database in the meantime. This separate and independent storage causes substantial coordination and data integrity problems.

It is impossible to ensure full data integrity among these two very separate worlds or even only to guarantee that all changes in one world are transferred to the other world without overwriting recent changes there - and vice versa.

Page and database are only two presentation forms of the same data entity. Data in a frame is in the database, not from the database.

Any change on either side will instantly affect the other side. No import or export is ever needed, no data integrity problems can possibly ever arise!

Any change on a page is done directly to the database data. Any change to the database will instantly affect all pages where this particular datum is visualized (unless a page has voluntarily been declared as frozen to explicitly protect its content from being changed).

No updates ever!

This is even true if part of the data is kept in your existing external database because EleStore is able to administrate virtual fields, which physically reside inside your existing database. Any update from ElePub will instantly be transported to your database so that data integrity will always be maintained even in such cases.

This is a real snap: you just change the central current language setting and upon re-loading a page it will show up in the other language!

No new page generation is needed, no import, export or whatsoever!

ElePub automatically accesses all texts in EleStore in the chosen language. Unfortunately German runs longer than English, and French even longer than German with Italian and Spanish in even better places for the longest running language. If frames were designed for English, they hardly ever will show the full text in Italian or Spanish.

Still, with ElePub there is typically no manual interaction needed. ElePub will recalculate all layout containers with all enclosed layouts, frames and tables and it will optimize the already designed pages. In some extreme cases this might need your decision but only to protect the same setting and number of pages. All the rest is done automatically by ElePub.

Templates are typically used to provide a pattern, which can be used for several cases.

Typically this is a one-to-many relation based on one level only, i.e. one template is used many times on several pages.

Things like multi-level sub-templates are unknown. Also, in most cases a template is only referenced at creation time and therefore any later change does not instantly affect the copies created earlier from the template. Here features may vary between different DTP products.

ElePub has no templates because ElePub has inheritance and inheritance as a concept is far superior to templates.

In ElePub mother objects provide in a much more flexible and powerful alternative to templates.

Mother objects offer inheritance over several levels. Each level has the ability to change (overwrite) only those attributes, in which it differs from its mother object. Also, in inheritances any change to a mother object will instantly affect any of this mother's children unless one of them has overwritten this particular attribute.