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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: About Constructions rules, Didier PH Martin | Thread | RE: About Constructions rules, Didier PH Martin |
RE: DSSSL engine in LISP? (also Re:, Didier PH Martin | Date | Re: DSSSL engine in LISP? (also Re:, Daniel Mahler |
Month |