Re: About Constructions rules

Subject: Re: About Constructions rules
From: Brandon Ibach <bibach@xxxxxxxxxxxxxx>
Date: Wed, 14 Jul 1999 20:52:25 -0500
Okay... this has almost gotten to the point where I can't even follow
it anymore! :P  So, it's time to take my shot at it.  I'm going to try
to lay out the gist of section 12.4.1 of the spec, which, when you get
right down to it, specifies the entire style language processing
model.  So, without further ado...

A document is processed according to a style specification by
processing the root node of the document grove.  Note that this is the
*only* node that gets explicitly processed by the DSSSL engine.  Any
other nodes that get processed are the result of things like
(process-children) and friends.  The result of processing this one
node is a SOSOFO which describes the entire output flow object tree.

Whenever a node is to be processed (whether it is the root node via
the DSSSL engine directly or another node due to (p-c) or whatever),
the engine must choose which construction rule to use.  Here's how it
decides:
   1. If there is a current mode (other than the default, unnamed
      mode) in use, and it contains rules which apply to the current
      node, then any rules outside of the mode are discarded.
   2. At this point, if there is more than one rule which applies to
      the current node, the one which appears first in the style spec
      will be used.  [Note: I'm not sure why this isn't the last thing
      to consider, eliminating the possibility of errors due to
      conflicting rules, but that's the way the spec is written.]
   3. If any (query) rules exist, and the first expression in any of
      them (the style-query-expression) returns a node list containing
      the current node, then whichever of these query rules returns
      the highest value for its priority-expression (the default for
      which, if no priority-expression is given, is 0) will be used.
      Note that, because (current-root) and (current-node) both return
      the root node of the grove, no query rule style-query-expression
      can ever be affected by the current state of processing.
      Therefore, it would be possible for the DSSSL engine to
      calculate the result of the style-query-expressions (and, I
      suppose, the priority-expressions, too) for all query rules
      before beginning processing, but I digress.
   4. If the current node is of class "element", and there is an ID
      rule which matches a unique identifier (accomplished via ID
      attributes in the DTD, I'd guess) of the node, then that rule
      will be used.
   5. If the current node is of class "element", and there is an
      Element rule which matches (I won't go into all the stuff about
      how this works with qualified GIs and such... I'm sure you all
      know that well, or can read the spec on it), it will be used.
      Note that the most specific element rule is the one with the
      longest match (longest qualified GI).
   6. If the current node is of class "element", and there is a
      Default Element rule, it will match.
   7. If the current node is of class "sgml-document", and there is a
      Root rule, it will match.
   8. If there still hasn't been a matching rule, then the default,
      implicit rules kick in, based on the node's class:
         sgml-document, element, or attribute-assignment:
               The result of (process-children) is returned
         char: The result of (make character) is returned
         anything else: The result of (empty-sosofo) is returned

So, I think that covers that.  To bring us back to the whole (query)
discussion, I'm afraid that I have to disagree with the approach
Didier is taking to this.
I believe the correct way to think about query construction rules is
that the style-query-expression is evaluated once before processing
begins.  Whenever a node needs to be processed (and modes don't keep
us from considering the query rule), we check to see if the node list
that we got back from the style-query-expression contains the node to
be processed.  If so, then we use that rule instead of an element rule
or whatever lower priority options there may be (taking into account,
of course, the priority-expressions, if there are multiple query
rules).  Really, the query rule lets you pick an arbitrary set of
nodes from the tree for special processing.  I think this could be a
great feature, as it may allow for a more efficient way to do some of
the stuff currently handled by modes which make multiple passes over
the tree.
As far as (sgml-parse) goes, I believe it returns a singleton node
list containing the root node of the new grove.  You should be able to
then pass this in to (process-node-list) (or something like that),
possibly within a special mode, to do what you want.  Didier, did you
envision something that wouldn't be possible with this type of
approach?

-Brandon :)


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


Current Thread