A Generalized Online Delivery Paradigm for XML Information

Christophe Lecluse is general manager of AIS Software. He has been working on SGML applications and systems for over eight years and specializes in SGML systems, object databases and languages. He was the originator of the Balise and Dual Prism products developed by AIS Software.

Introduction

A "Web-publishing" Definition

A "Functional" Definition

Typical Online Delivery Applications

Common Characteristics: Dynamicity and Various Information Sources

Challenge: Reduce Development and Maintenance Cost for Applications

Proposal for a Dynamic Web Delivery Framework

A Repository for XML Data

Structure Style Sheets : Controlling XML Module Fragmentation and Indexing

 
Fragmentation
 
  Controlling XML module fragmentation in the XML repository is important as we want the model to apply to a   wide range of applications when XML modules can be of very different sizes. Typical examples could be:  
 
a J2008 module (10 to 100Kb)  
 
a catalog page (less than 10 Kb)  
 
a DOCBOOK chapter, or a full book (from 10 Kb to 4Mb)  
 
an ATA manual (from 10Mb to 150Mb)  

 
  Only small fragments can be efficiently manipulated and transferred by the delivery server at a given time. The   structure style sheet allows the application designer to express rules that are used by the repository to split a   given module into a hierarchy of smaller fragments that become the elementary units for the server.   
 
  Typical properties expressed in Structure Style Sheets rules are the following:  
 
New-Page property : start a new fragment for a given container tag (CHAPTER, SECTION, IPC-PAGE, etc.)  
 
No-Break property : make sure that the element is not splitted between two fragments.  

 
  Properties are associated to XML elements names (CHAPTER) or XML element contexts (SECTION in   CHAPTER).  

 
Table of Contents
 
  Structure Style Sheets also contain some properties that express how table of contents should be generated (if   needed) for each module. Those properties are:  
 
Toc-Names property : adds the given container tag to the listed table of contents.  
 
Title property: used to indicate the title that should be used to represent the container tag in the table of   content.  

 
  Table of contents properties will be set for all XML tags that should appear in one or several tables of contents.   This specification allows a completely automatic table of content generation process to take place.  

 
Indexing
 
  Being able to search over a collection of XML modules is of course a major requirement for an XML repository.   A generic XML searching engine must be able to search on text, tags, attribute values (and any combination of   those). Many application, however, also require specific indexes to be constructed :  
 
an index that associates a section title to an ID for presenting section titles in cross reference elements,  
 
an index that associates a figure to a part reference to be able to insert an icon whenever the part reference is   encountered in the document module.  

 
Of course, such selections could be dynamically computed from the underlying generic indexes (using some kind   of XML query language). However, XML query evaluation is complex and difficult to optimize, so this could   rapidly become a performance bottleneck for very dynamic applications.   
 
We thus enable the creation of custom indexes that are constructed and stored in the repository. A custom index   maps character strings (keys) to lists of objects of various kinds (values). These objects can be strings, numbers,    or XML elements in the repository.  

 
Example
 
  <STYLE NAME='SEC1' INHERIT='#DEFAULT'>   <NEW-PAGE>"true"</NEW-PAGE>   <TOC-NAME>"tableOfContent , listOfFigures"</TOC-NAME>   <TITLE> child("TSECT1") </TITLE>   <CUSTOM> addEntry("XREF",attribute("ID"),child("TSECT1")) </CUSTOM>  </STYLE>  <STYLE NAME='SEC2' INHERIT='#DEFAULT'>   <NEW-PAGE>"true"</NEW-PAGE>   <TOC-NAME>"tableOfContent"</TOC-NAME>   <TITLE> child("TSECT2") </TITLE>  . . .  

 
Scripting
 
All properties in style sheets or templates can be either simple values (like the value of the NEW-PAGE property   above) or can be computed using an expression (like the value of the TITLE property above). In Dual Prism, we   use the Balise language for scripting.   
 
  Expressions in Structure Style Sheets are able to access any XML information in the repository. The   child("TSECT1") example above specifies that the title to be used in the table of contents for the SECT1 element   should be retrieved by searching for the first child of the SECT1 element with the name TSECT1. All navigation   primitives defined in the W3C DOM (Document Object Model) are available here, together with general data   manipulation functions.  

Templates : the Central Component

 
Example : A Template fetching a Product List from a Database
 
  <DP:TEMPLATE>    <DP:SCRIPT>    function fetchProductList ( )    {      // send an SQL query to a RDB      . . .      // return a list of items, with fields REFERENCE and DESCRIPTION    }   </DP:SCRIPT>     <HTML><BODY>   <TABLE BORDER="1">    <DP:FOREACH ITEMS='{ fetchProductList( ) }'>      <TR><TD><DP:EVAL>item( ) ["REFERENCE"]</DP:EVAL></TD>   <TD><DP:EVAL>item ( ) ["DESCRIPTION"]</DP:EVAL></TD>      </TR>    </DP:FOREACH>   </TABLE>   </BODY></HTML>  </DP:TEMPLATE>  

 
Example : A Template Displaying an XML Fragment
 
  <DP:TEMPLATE module='*'>  <HTML><BODY>    <HR/>      <DP:RENDER module = '{ param("module") }' rstyle='default' />  ..<HR/>    <P>This page has been dynamically generated by Dual Prism</P>  </BODY></HTML>  </DP:TEMPLATE>  
 
  In this example, the template takes a required parameter called "module". This parameter contains the name   (identifier) of a module in the repository. It generates an HTML page with a top and bottom rule, and triggers the   rendering style sheet called "default" on the given module. All tags produced by applying the rendering style   sheet on the module are inserted in place of the DP:RENDER tag.  

 
Example : A Template Displaying a dynamically assembled XML Fragment
 
  <DP:TEMPLATE >  <DP:SCRIPT>    function assemblePage ( )    {      // parse XML file 1      /  parse XML file 2      // merge the two XML tree      // return the merged XML tree    }   </DP:SCRIPT>    <HTML><BODY>    <HR/>      <DP:RENDER node = '{ assemblePage() }' rstyle='page' />  ..<HR/>    <P>This page has been dynamically generated by Dual Prism</P>  </BODY></HTML>  </DP:TEMPLATE>  
 
In this example, the assemblePage function is called. This function dynamically assembles of an XML fragment   from various sources (XML files that are parsed, SQL queries, or other sources). Then the resulting XML   fragment is passed to the DP:RENDER tag to be rendered using a rendering style sheet called "page".  

Rendering Style Sheets : On the Fly Generation of HTML for a Fragment

 
Example: Simple Rendering
 
  <STYLE NAME='ILIST' INHERIT='#DEFAULT'>   <TAG>"UL"</TAG>  </STYLE>  <STYLE NAME='ITEM' INHERIT='#DEFAULT'>   <TAG>"LI"</TAG>  </STYLE>  <STYLE NAME='P' INHERIT='#DEFAULT'>   <TAG>"P"</TAG>  </STYLE>  
 
  The simplest rendering style sheet property is the Tag property that maps a given XML element to a rendering   element, here the HTML UL, LI and P elements. Other properties allow prefix and suffix generation, CSS elements   and attribute generations, automatic generation of HTML links and anchors, etc.  

 
Example: Using Expressions for Dynamicity
 
  <STYLE NAME='FLETTER' INHERIT='#DEFAULT'>   <TAG>"P"</TAG>   <TEXT-BEFORE> fetchInDB(attribute("LETTER")) </TEXT-BEFORE>  </STYLE>  
 
  In this example, a script function (fetchInDB) is called with an attribute value extracted from the FLETTER   element. The possibility to call any scripting function when evaluating a rendering style sheet property is   essential for merging various sources of information in a consistent way, and for implementing all sorts of   dynamic filtering and assembly down to the XML element level.  

 
Relationship with XML and XSL
 
  Our rendering style sheet have a role in the framework that is very similar to the role planned for the forthcoming   XSL standard, even if this standard is referred to as a way of expressing XML rendering at the browser level, not   at the server level.  
 
  As soon as XSL proposals will stabilize into a W3C standard, it will be the perfect candidate for modeling the   rendering style sheet part of our framework. We plan to use XSL for rendering in the Dual Prism product.  
 
  HTML or XML can be used as the rendering format. Templates and rendering style sheets produce flows of   tagged data (they actually produce trees of elements and content). Today's applications use the HTML   vocabulary as it is the one understood by the current generation of browsers, but XML fragments could be   generated for display if browsers could understand and interpret them.  
 
  When this will be possible, XSL will also take a place at the browser level for interpreting and displaying XML   fragments dynamically generated by the server. The rendering engine in the server will be limited to filtering and   assembly tasks and will not "render/convert" the XML tags anymore.  

Scripting at Every Corner