Re: About Constructions rules

Subject: Re: About Constructions rules
From: Brandon Ibach <bibach@xxxxxxxxxxxxxx>
Date: Thu, 15 Jul 1999 17:28:11 -0500
Quoting Avi Kivity <Avi@xxxxxxxxxxxxx>:
> Dsssl only specifies that one node is processed -- the root node. Of course,
> if you leave the default processing rules, you get a recursive descent. But
> each level of recursion goes through the stylesheet, which usually goes to
> the next level using (process-children).
> 
   Correct... it is very important to realize that the DSSSL engine
only ever *explicitly* processes the root node, and that all other
processing is due to instructions to do so in the stylesheet, whether
via explicit calls to (process-children) and friends, or by implicit
calls to it, compliments of the default node processing rules.
   Herein lies the problem I have with what Avi is saying, or at least
the point of misunderstanding between us in all of this.  As it
stands, Jade provides no way to override the default (make character)
rule for char nodes.  If the query feature were present, however, it
could potentially affect char nodes.  Avi, I agree with your 5 points
on the handling of query rules.  No exceptions whatsoever.  But,
consider point 5 for a moment:

> 5. When a node's turn to be processed comes, if it is in the node-list
> returned by the q-c-r, the corresponding sosofo is inserted.
> 
   The key here is "if it is in the node-list".  In the case of your
average DSSSL application, every node in the grove, with the possible
exception of some attribute-assignments and such, will be processed,
one way or another.  Therefore, because query rules are almost always
the first to be considered when choosing a rule to process a node,
almost every single node in the entire grove will have to be
considered for processing by the query rule, meaning that we'll have
to check, for almost every single node, to see whether it's in the
node-list.  I think the point being made here is that this has the
potential to be an efficiency problem.
   So, can we acknowledge the *possible* efficiency problem, even if,
as Matthias and I have suggested, there may be some relatively easy
solutions?

-Brandon :)

PS- Remember, tune in again for the next exciting episode of:
    "Celebrity DSSSL Death Match"!!!  ;)


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


Current Thread