ESciDoc Developer Telco 2008-02-26

ESciDoc

Topic: Containers and TOC Date: 26.02.2008 Participants: Natasa, Wilhelm, Matthias, Frank, Harald

Alternatives for TOC implementation
a) A full Toc actually consists of one or more smaller TOC objects at level of each aggregation (Container) ((i will call this aggregation-level-Toc)) in a well defined structure and a cached read-only full-Toc for fast retrieval

Advantages:
 * FW can provide automatically update of all Toc objects whenever aggregation member is added/deleted/withdrawn (in case that is configured for Toc).
 * FW can provide integrity checking and make sure that the Toc object is always in sync with the Struct map (i.e. no objects will be referenced in the aggregation-level-Toc that are not really members of that aggregation)

Disadvantages:
 * In case solution needs to make an update of complete Toc (at any level of the aggregation) solution will have to update as many aggregation-level-Tocs as necessary (regarded use case: sort objects alphabetically within each aggregation level in the Toc)

b) A full Toc is a separate object, maintained by the solution, FW provides relations from aggregation object to the Toc object

Advantages:
 * single operation to update any part of the Toc object, independent versioning
 * Toc object can undergo the standard workflow (pending, submitted, released), support for different viewers

Disadvantages:
 * FW can not control the Toc object
 * Toc owners have to make "manual" synchronization (with evtl. provided framework utilities)

Discussion
We have discussed both alternatives and came to the conclusion that we still need to re-think them all. Here just put my understanding of the issues we need to rework and find fast solution for:


 * 1) Full TOC as separate object makes sense when we deal with some more complex SWB use cases (i.e. automated sorting)
 * 2) Full (or cached) TOC object is preferrable to be served for retrieval/update to the solution (and if FW internally keeps aggregation-level-Toc objects, the FW should cascade this operation where needed)
 * 3) Full TOC objects must not necessarily be "viewer" dependent, this can be done by providing an extra stylesheet for different viewers
 * 4) Instead of aggregation-level-Toc objects for each aggregation one may have single (full) Toc object in an agreed structure (that can be controlled by the FW) and "slots" for extra information for each node that will be controlled by the solution . All aggregations referenced in this TOC object can have links (relations) to it (not only the top-level-aggregation) (in this case we can probably benefit from both approaches depicted for a, b above?)
 * 5) We need to understand that a modification of the TOC object is not a new version of the container (but a new version of the TOC object)

Scholarly workbench scenarios SVN