Menu
▾
▴
#258 doctools - General tree representation as backend API
This is 'way out there'-RFE.
Currently the generic layer of the low-level doctools engine uses textutil::expander to parse the input in general, a checker layer to check that the commands are in the correct order, and then calls the appropriate formatting function in the backend. Sort of like a SAX API for XML processing. The backend gets various events and has to make sense of them, although it can be sure that it will not get events in a bad order.
Consider to rework the generic layer to create a tree structure representing the document. This tree is then given to the backend for conversion into the output format. Instead of each backend having to pull out the document structure out of the series of events this is done in the generic layer, and the backend's responsibility shrinks to only doing the actual conversion into output.
There is a drawback. There are backends which are much better served by the event stream, because they do not care about the structure, or at least not very much. Examples of these are:
Existing: null, list
Proposed: wordlist, semantic
So, best might be to try and accomodate both, i.e. load the backend, query it for its mode of operation, event stream or document tree, then setup the remainder of the processing pipe.
Note: This tree-based API is very similar to the general API used in PAGE, i.e. backends based on it could be used by this general text processing tool, and the processing pipe for creating the tree might make a suitable reader plugin for PAGE too.
