RenderObjects processing model

Processing model

The processing model works with objects of all range-types, i.e., objects which are either "SINGLE RANGE OBJECTS", "SINGLE MONAD OBJECTS", or "MULTIPLE RANGE OBJECTS".

The algorithm is as follows:

1. Start the process by calling RenderObjects::startDocument(). The default implementation of startDocument() just adds the XML declaration to the document. The user is free to subclass the RenderObjects class and reimplement startDocument, thus starting in a different way.

2. Based on the starting and ending monads given in the parameters to the RenderObejcts::process() call, all objects from the object types present in the "object_types" JSON object of the given "fetch style sheet" are read into memory. This is done with a GET OBJECTS HAVING MONADS IN { first_monad - last_monad } MQL statement.

3. The objects read into memory are then processed as follows:

   For all monads m between the first monad and the last monad:

   1. Get a list of objects which start at the monad m, or which have a monad set element which starts at m. Sort it according to the methods specified below. For each object in this sorted list, call the "template" specified in the "start" value in the "object_types" JSON object for this object type.

   2. Get a list of objects which end at monad m, or which have a monad set element which ends at m. Sort it according to the methods specified below. For each object in this list, call the "template" specified in the "end" value in the "object_types" JSON object for this object type.

Sorting methods

When sorting the lists of objects to start or end at a given monad, the following two methods can be used:

1. priority_list:

   If the stylesheet JSON object contains a "priority_list" key (as described above), then the list is sorted by two keys: First, by the last monad of the Monad Set Element which starts at the current monad (in reverse order). And second, by the position of the object type in the priority_list JSON array. The effect of this is that objects which start at the same monad are opened first if they end later, and, if they end at the same monad, are opened first if they are first in the priority_list. Thus, if you have a DTD that you want to follow, and element X contains element Y in the DTD, you can safely place X before Y in the priority_list and assume that everything is printed in the right order.

   This is reversed when doing the end-of-Monad-set-element monad. That is, the first monad of the monad set element at hand is used as the first sorting key, and the length of the priority list MINUS the position of the object type in the priority list is used as the second sorting key. Thus, objects which start after other objects are closed first, and objects which start at the same monad, but are further down in the priority_list are closed first. Again, this is so as to ensure that a DTD is followed if element X contains element Y, and element X is before element Y in the priority list.

2. document index feature:

   The other method that can be used to sort the list is to use a "document index feature". The concrete expression of this in the stylesheet is given below, under "Object type information". For now, it is enough to know that a document index feature is an integer feature on an object which gives, for that object, the priority to be used. Thus it replaces the priority_list. Indeed, if there is no priority_list, then all objects in the object_types JSON object MUST have a "docindexfeature" key. Conversely, if there is a "priority_list", then that will be used, regardless of whether any object type JSON object has a "docindexfeature" key.

   The "document index feature" must be generated (when you generate the database) in such a way that objects with lower document index feature values are to be "started" before objects with higher document index feature values, and ended after objects with higher document index feature values.

   Note that the algorithm completely disregards the first and last monads of the monad set element in the sorting of those that start or end a monad set element at a given monad. This is because the algorithm needs to trust the docindexfeature value completely.

   Note also that this can usefully implemented by "parents": If an object has a parent, then that parent's docindexfeature should always be lower than any of its children. That way, if it is a tree, then the objects will be started and ended in a cleanly nested way.

   Note also that if this is a tree (and not a forest of connecected trees with a common root), then the parent need not have a globally unique docindexfeature. Instead, the docindexfeature values must be locally unique within the tree.

Object type information

For each object type in the "object_types" JSON object, the following four keys may be present:

• get: If present, this must map to a JSON list of JSON strings. The strings must be features present on the given object type.
• start: If present, this must map to a JSON string which gives the "template" to be used when starting objects of this object type.
• end: If present, this must map to a JSON string which gives the "template" to be used when ending objects of this object type.
• docindexfeature: If present, the the feature named by the value must be an integer, suitable for being used by the "document index feature" algorithm described above for prioritizing objects.

Templates

As stated, the "start" and "end" keys must map to JSON strings which contain "templates". In the next Section, we describe these templates.