6. Comparing the CP Split to Alternative Technologies

As discussed in the previous posts, the nodes use the CP Split’s patented process uses template models to:

1. Create Content Configurations in a Content File Production Grid (CFP) Grid using spreadsheet and third-party applications
2. Transfer these Content Configurations into a Content File for storage and distribution
3. Transfer the Content Configurations from the Content File into a Content File Consumption (CFC) Grid where (a) formatting instructions from spreadsheet and third-party applications present reports by rendering each content element based on its location within the spreadsheet and (b) the content elements may also be sent to populate databases.

This process differentiates the CP Split from all other technologies used for the distribution and presentation of reports. Following is a discussion of these differences and the benefits of using the CP Split technology.

How Does the CP Split Differ from Database Report Writers?

The CP Split technology differs from database report writers in the following operations:

• Database report writers and the CP Split differ in the way they retrieve the content for a report:
  • With a database report writer, the end user/client (i.e., a Subscriber node) must query a database, and indicate how the returned data are to be analyzed and formatted. The user selects predefined report formats or creates new ones.
  • With the CP Split, the end user does not query a database when generating a report. Instead, a Publisher node does any required database querying, as well as any required data analyses and other non-formatting manipulations of the data returned from the queries. It then organizes the resulting content into Content Configurations in its CFP Grid. The framework (grid-based structure) for organizing the content into configurations are created when the Publisher and Subscriber/Presenter Templates are developed and assure that the Content Configurations in the Publisher's CFP Grid correspond to their Subscribers’ CFC Grids (the next post discusses best practices for building the Content Configurations). Like the database reports, the queries, analytics, and formats may be predefined for its Subscribers, or new ones may be created via instructions from Subscriber nodes.
• Once the data queries and analytics are done, the resulting content must be formatted for report presentation. Types of report formats include columnar, crosstab, form, label, and OLAP/pivot table, and their views may include graphs/charts, lists, tables, text boxes, and more. Database report writers and the CP Split differ in the way they manage and format content for presentation:
  • Database report writers render queried content through instructions that format content elements based on their fields (and possibly other attributes). Reports can be published to a variety of file formats for distribution, including XML, PDF, HTML, RTF, Word, Excel, text, and more.
  • With the CP Split, the Publisher node places the Content Configurations from the CFP Grid to Content Files for storage and transmission, and then sends the files to its Subscriber nodes. Upon receipt, each Subscriber node places the Content Configurations from the Content File into its CFC Grid and formats the content elements for presentation through formatting instructions applied to particular content elements based on their cell locations in the CFC Grid.

Compared to database report writers, the CP Split has distinct advantages when disseminating interactive reports containing numeric values and related visualizations (e.g., charts/graphs, etc.). This is because the CP Split technology keeps the numeric content "live" – i.e., the numbers are not embedded in markup tags or converted to text – so they are ready for reuse immediately. This means there is no need to re-entry the data, use screen scrapers, or do time-consuming data parsing and transformations when using the CP Split. Furthermore, the CP Split enables content to be transmitted in its most efficient form, i.e., in delimited formats (such as in CSV files) that contain no formatting instructions, markup tags, or programming code.

How Does the CP Split Differ from Spreadsheet Reports?

To understand the CP Split more fully, it is necessary to compare it to technologies beyond database report writers.

For example, it is possible to distribute entire spreadsheet workbooks filled with the content, formatting instructions and macros. This is a very inefficient approach because every time the content is updated or used by a different model, new workbooks must be distributed, which can be very large (many megabytes). This approach also makes it difficult to track changes made to the content or models over time - for auditing purposes for example - since multiple version of the workbooks must be stored, which can require complex versioning controls.

A more sensible and elegant method for delivering report updates is to use the CP Split to distribute the content, and only the content, in delimited text Content Files. These files are a tiny fraction of the size of entire workbooks because they do not contain formatting instructions, code, or markup tags. In addition, they provide easy auditing (through change management methods) and file management (by using ID numbers to maintain the proper association between Content Files and the template files that produce and consume them). The workbooks containing the models are only redistributed if the models represented in the templates changes, which may me necessary, for example, if the schema of the source data changes.

Benefits of the CP Split Technology

The benefits of this unique approach are realized when content is shared between nodes using different template models to generate different reports, or between different nodes with the same template model to generate the same report.

The CP Split technology, therefore, offers this unique set of benefits:

• Content from diverse sources can be integrated and stored in a uniform structure for use across multiple platforms and applications, which provides a simple, transparent (human readable), and auditable interoperable architecture


• Different audiences can receive different portions of the content and have it rendered in particular ways based on what they need for personalized reports


• Content can be integrated from different sources easily for distributing composite reports


• Portions of a Content File can be sent to different sources (e.g., to populate a data warehouse)


• Content can be manipulated (e.g., analyzed, adjusted, transformed) without costly conversion from appearance-based text representations


• Content can be repurposed quickly and easily for different presentation media


• Content is transported in smaller files that consume less bandwidth because they do not contain formatting instructions, markup tags, or code


• Exceptional speed and efficiency is achieved when dealing with numbers and computations, and when generating charts and graphs, because the Content Configurations can be distributed in their proper "serialized" order, which enables rendering engines to generate charts and graphs more quickly and easily


• Different models with different formulas can be used to calculate the same set of data from a Content File, and sets of data from Content Files can be modified on-the-fly to accommodate different computational models (e.g., when doing real-time "what-if" scenarios, when slicing & dicing aggregated data) -- all without complex or time-consuming pre-processing, e.g., there is no need for database queries, for XML parsing and XSLT transformations, and for online analytic processing (OLAP) by the client (see RocketOLAP™)


• Changes can be made to the data in a model and those changes distributed as necessary, which is important when (a) editing out mistakes or updating sets of data, (b) creating and analyzing what-if scenarios, and (c) computing the same set of data using several analytic models because these activities may require somewhat different data.


• Data can be added to a model and those additions distributed when necessary, which is important in collaborative situations when (a) different people must input data to complete a data set, (b) automated (unmanned) nodes supply data, and (c) several analytic models are used to compute the same set of data, and certain models require additional data


• Portions of a data set can be restricted from being accessed by particular models, which is important when different users with different roles require only a portion of a data set; it helps assure people get to see only the data they need to minimize information overload and protect data from being viewed by unauthorized persons


• Content can be "scrambled" for a unique form of security that is forever immune to brute force attacks (see MultiCryption™).