Re: Repeated question on selection order

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