Re: Issues with literate programming DSSSL Script

[MARK.WROTH@xxxxxxxxxxx (Wroth, Mark)]

"Russell Steven Shawn O'Connor" <roconnor@xxxxxxxxxxxx>
commented on the use of formatting-instructions

RSSO'C>On Mon, 20 Dec 1999, Wroth, Mark wrote:
RSSO'C>
RSSO'C>> DC>	  (make formatting-instruction
RSSO'C>> DC>		data:   "&#60;"
RSSO'C>
RSSO'C>I think the idea is to use formatting-instruction for *everything*.
RSSO'C>
RSSO'C>ex.
RSSO'C>
RSSO'C>(make formatting-instruction data: (string-append "package "
RSSO'C>(*some-command-of-yours* (tree-root))))
RSSO'C>
RSSO'C>or whatever you want to do.  formatting-instruction works just as
well for
RSSO'C>normal characters as it does for special characters.
RSSO'C>
RSSO'C>At least this is my understanding.

and Brandon Ibach <bibach@xxxxxxxxxxxxxx> commented

BI>   Your essential problem arises when you allow DSSSL's default node
BI>rules to process your data.  By default (and you can't really change
BI>this, in current versions of [Open]Jade), a data-character node in
BI>your document grove will become a character flow object in the output
BI>flow object tree.  Unfortunately (for you), certain character flow
BI>objects in the output FOT for the SGML backend get replaced by entity
BI>references.  The way around this is to use the formatting-instruction
BI>flow object, instead, which doesn't do *anything* to its data.
BI>   So, the trick is to, in any situation where you have some text that
BI>you don't want turned into entity references, prevent the default
BI>character rule from firing, and output a formatting-instruction
BI>instead.  I would think, just guessing about how your system works,
BI>that you've got one or more elements that contain source code.  So, if
BI>you just did:
BI>	(element source
BI>	  (make formatting-instruction
BI>	    data: (data (current-node))))
BI>
BI>you should get what you want.
BI>   Hope that makes things clearer. :)

I think you are both getting at the same idea, which I understand to be to
process the entire node containing the code as a formatting instruction in
order to disable the parser's attempts to deal with syntactically
significant punctuation.

	Unfortunately, I apparently did not specify the problem well enough.
Some of the contents of the node are SGML markup (specifically pointers to
other code scraps which are to be inserted in the output code block).  So an
example might be 

<scrap id="scrap1">
<title>Outside Loop</title>
While (a < max_a)
	<scrapref id="scrap2">
end
</scrap>

<scrap id="scrap2">
<title>Conditional increment of a</title>
	increment(a) if z > a
</scrap>

<scrap continues="scrap1">
print("the current value of a is ", a)
</scrap>

This will result in the following code:

while (a < max_a)
		increment(a) if z > a
end
print("the current value of a is ", a)


So I can't just treat the contents of a code scrap as unparsed CDATA; there
are elements (and potentially entities) which must be parsed.

(Incidentally, in the "solution" I proposed, we would have to write, for
example,
"(a < b)" as "(a &lt; b)" or worse "(a <literal data="<"> b)". I'm not
wildly enthused about either of these from the standpoint of source file
entry and editing, but I think the entity version is tolerable.)


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