SGML Transformation

Scripts and utilities for general SGML transformation

Random Possible Features and Improvements

>>>NOTE>>> ****** need make rule for *.status -> *.pod finish the status files and test pods generated perl -M'lib ("../perl-local")' ../ASM-ProjectNotes/podify ElementMap.status ElementMap.pod add mechanism where the handlers queue "event" objects and the engine can be called in a get-next-event style. Does this maintain any use for the engine's work? Maybe allow registration of "handlers" that are just notes on what events to queue change single arg handler to use xpath. "ELNAME" is relative xpath expr that tests name of current context--ie it is backwards compatible with single arg form. Except that xpaths dont need a "type" for the handler Python XPath: Python's EventDOM is like my TE with XPaths Orchard will have a pull interface > The editor -- v1.5.16 of the Emacs lisp package table.el created by > Takaaki (Tak) Ota  <<<NOTE<<<


Not worth it?: Change the stack mechanism so that empty frames are counted instead of being created and manipulated. Keep a variable that is the "empty frame count." When a stack variable is defined, add a new frame if the empty frame count is greater than zero. When a context is exited, delete the current frame only if the empty frame count is zero, otherwise decrememnt the empty frame count. Adding a new frame involves saving the previous value of the empty frame count, and popping a frame involves restoring the value. Entering a context increases the empty frame count by 1.

Add a mechanism for more complex event handling--essentially a callback mechanism in to the transform process. This is motivated by the need to use functions which add/update stack variables and need to be able to act when those variables are popped, to update parent stack variables for example (adding stack levels cannot solve this, as it will catch other stack variable users by suprise). The stack should be externalized and managed by these same event functions. The whole SGML-specific code may possibly be factored out with this--then what will the module be called?

callback events: element, sdata, extentity, subdoc, pi, re, cdata, comment, conforming

callback points: before, normal, after

only one normal callback will get executed. essential/atomic callbacks will all execute in order when applicable.

Context Expressions

>>>NOTE>>> Status: conceptualization. Need to asses XPath  <<<NOTE<<<

This module should abstract the context handling and matching so client programs have simple and intelligible ways to define matching rules.

Set the environment context with a coderef, a string, or a (?). Either let a string environment-constructing-command be passed, or use functions to specify the context.

current env point has parent named 'p1'. p1 hs an ancestor named p2. p1 also has an attribute 'hi' set to 3.

attribute changes the "focus" of the node, so we still have a node, but now if we look at it, we'll see the attribute.

prepare element constraints into regular expression, if RE matches, then test attribute constraints. Build tree fragment from query, then collapse the tree into a RE. Add a number to element names in the context string, then the numbers can be captured by the match test, and the numbers can index the history to find the node for attribute tests.

Context matcher needs to know if it has access to the whole grove, and if it will need that access, so the engine knows how much to parse. The context code should build a tree fragment that represents all the handler contexts, then it can tell which points it will need to parse farther ahead for possible constraints. Maybe add some rules that can assist it here, like "X can only be in Y".

"or" makes a pair of possible matches from its arguments. It can be used on elements or value expressions.

Allow handler to call for the named nodes in the context tree, so the context is also an assertion of values to use in processing?