Subject: Re: Repeated question on selection order From: Brandon Ibach <bibach@xxxxxxxxxxxxxx> Date: Mon, 20 Dec 1999 14:36:46 -0600 |
Quoting Wroth, Mark <MARK.WROTH@xxxxxxxxxxx>: > But I still have a theoretical question. When I use the code > > (with-mode continuation > (make sequence > (process-node-list > (select-elements (descendants (document-element > (current-node))) > `(scrap (continues ,(attribute-string "id"))))))) > > I am guaranteed by the DSSSL specification (paragraph 12.4.3) that the > process-node-list function will process the node list *in order*. However, > I can't tell from the text of 10.2.5 whether I can guarantee that > select-elements will produce a node list in the order I desire (which is the > order the matching elements appear in the document instance). The practical > examples I've run seem to indicate that Jade, at least, does so. But since > a variation in the selection order would have ... interesting ... > possibilities for introducing bugs into the output program source code, I'd > like to be sure that this is not mere coincidence. > Well, I can't say for sure, as the spec isn't real clear on this issue, but my money is that you'll find Jade's behavior to be the consistent model. Node lists are (according to the intro to Chapter 10) inherently ordered, and the select-elements function is only supposed to filter the node-list. For it to do anything more than that (including reordering it) would be outside of its specification, at least in my mind. So, given that the descendants function, according to the spec, will always return the node list in tree order, you should be safe. :) > Hmmm. I'm still not sure I understand what you're getting at. I did, > however, come up with a "solution" that uses the formatting-instruction. I > define an element <literal> with one required attribute, which is the > literal data. I then use an element rule like: > > (element literal > (make formatting-instruction > data: (attribute-string "data"))) > > This allows me to insert <literal data="<"> in the document (or, more > pragmatically, define an entity which does so). I still don't see a way to > do this without defining an element in the DTD, but this works acceptably. > Your essential problem arises when you allow DSSSL's default node rules to process your data. By default (and you can't really change this, in current versions of [Open]Jade), a data-character node in your document grove will become a character flow object in the output flow object tree. Unfortunately (for you), certain character flow objects in the output FOT for the SGML backend get replaced by entity references. The way around this is to use the formatting-instruction flow object, instead, which doesn't do *anything* to its data. So, the trick is to, in any situation where you have some text that you don't want turned into entity references, prevent the default character rule from firing, and output a formatting-instruction instead. I would think, just guessing about how your system works, that you've got one or more elements that contain source code. So, if you just did: (element source (make formatting-instruction data: (data (current-node)))) you should get what you want. Hope that makes things clearer. :) -Brandon :) DSSSList info and archive: http://www.mulberrytech.com/dsssl/dssslist
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Repeated question on selection orde, Wroth, Mark | Thread | Re: Repeated question on selection , Wroth, Mark |
Re: Issues with literate programmin, Russell Steven Shawn | Date | Re: support for 'macro' formatting , Sebastian Rahtz |
Month |