Re: Side effects and large-scale conversion

[Chris Maden <crism@xxxxxxx>]

[Sam Hunting]
> Has anyone ever used DSSSL for large-scale conversion (1000s of
> pages) -- doubtful -- and if so, did the prohibition of side effects
> get in the way?  Why or why not?

I converted 597 pages to MIF.

The lack of side effects is inconvenient due to the linear nature of
MIF.  Consider this DocBook fragment:

<Para>Then you can type <Literal>rm <Replaceable>options</Replaceable>
-r</Literal> and get this:
<ProgramListing>
I ate all your files!
Ha ha ha!
</ProgramListing>
which isn't very good.</Para>

This needs to become the following, in English:

o Start a "Body" paragraph with no special font.
o Change to the "Literal" font.
o Change to the "Replaceable" font.
o Change to the "Literal" font.
o Change to the null font.
o End the current paragraph.
o Start a "CodeIndent" paragraph.
o End the current paragraph and start a new "CodeIndent" paragraph.
o End the current paragraph and start a "Body" paragraph.
o End the current paragraph.

The problem is the lack of a stack.  When I process the node for
<Replaceable>, I need to restore the MIF FTag to "Literal" when its
done.  But the Replaceable construction rule has no idea what to
restore its font to[*].  What I've done is, in the procedure that
handles mixed content[**], the current FTag is restored after
processing any inline element.  This is cumbersome, but not
impossible.  The same can be done with sub-paragraphs.

Anything that you might want side-effects for, you can do by making
the same decisions again from the current context.  This is unweildy
in the extreme, but not impossible.  Regard it as a challenge. (-:

-Chris

[*] Yes, I could explicitly case all of its ancestors, and those of
all the other potential inline elements.  This would be extremely
painful.
[**] To escape special characters and to process SDATA entities into
their MIF equivalents.
-- 
<!NOTATION SGML.Geek PUBLIC "-//Anonymous//NOTATION SGML Geek//EN">
<!ENTITY crism PUBLIC "-//O'Reilly//NONSGML Christopher R. Maden//EN"
"<URL>http://www.oreilly.com/people/staff/crism/ <TEL>+1.617.499.7487
<USMAIL>90 Sherman Street, Cambridge, MA 02140 USA" NDATA SGML.Geek>

 DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist