Subject: RE: About Constructions rules From: "Didier PH Martin" <martind@xxxxxxxxxxxxx> Date: Wed, 14 Jul 1999 11:52:20 -0400 |
Hi Peter, Peter said: But it will only get processed if that node appears in the source grove. The query expression is for matching nodes more generally than the other expressions, not for inclusion. This might be worth noting. Didier says: I thought a lot about your comment and let's clarify it by sharing our thoughts and knowledge about it. a) The construction rule firing mechanism is based on a kind of loop. First a node is obtained from the source grove. Then the construction rule list is enumerated an element at a time for a pattern match. this happens for construction rules like: root, element, id, default, query. b) if a construction rule list element match the source node, the rule is fired and its content-construct executed. Do you mean that the query construction rule's query-expression part is constrained to be restricted to a current-node query expression. Said differently, that the query could only be expressed on the current-node sub list or node list elements? the spec says about the query construction rule: [164] query-construction-rule = (query style-query-expression construct-expression priority-expression?) A query-construction-rule matches any node in the node-list returned by the style-query-expression. query-construction-rules require the query feature. [165] style-query-expression = expression A style-query-expression shall return an object of type node-list. Within a style-query-expression, the current-root and current-node procedures both return the grove root of the grove being processed. [167] priority-expression = expression The priority-expression specifies the priority of the query-construction-rule. It shall evaluate to a number. If the priority-expression is omitted, then the priority shall be 0. Bigger numbers indicate higher priorities. nothing more is said. So let's interpret it :-)) Now, by reading the spec "as is", a query construction rule is OK as long as it returns a node list. This is this kind of premises I used in my document, and I am happy you brought the problem, so that we have the occasion to think about this missing in OpenJade, but important and useful construction rule. If a query rule is valid, as long as it contains a query-expression returning a node-list, this implies that the query rule will be fired for each loop. Thus, each time a source node is processed, the rule is fired. This implies, in the example I used (the sgml-parse query-expression) that the rule is fired for each source nodes ( a construction rule process loop) and then a sgml-parse executed for each source nodes. The other interpretation is to restrict the query construction rule to be valid only on current-node sub elements or node list. This time, only the node's children list members could be queried. The rule will also be fired for each source node and thus called for each processing loop. However, in this case, the query-expression is executed on the current-node and if it returns a node list, the construct-expression executed. Thus, in this case, the rule is also executed for each processing loop and the action is determined by the query-expression returned value. A third interpretation would be that the priority expression is the way to include or not the rule in the processing loop. So, for example, the sgml-parse is fired on the first processing loop, then because we got back a node list, the construct-expression do something with the included grove like process-children) and reset the priority-expression to 0 (but not in this respective order - the priority-expression should be set to zero first). By setting the priority-expression to zero, we tell the DSSSL engine that the rule is not fired anymore for all subsequent processing loop. So that way, the query is executed only once. I think that the editor intention is more the third interpretation and thus the following construction rule would be valid and executed only once: (define priority 1) (query (sgml-parse "<url>http://www.netfolder.com/doc.sgml") (let(priority 0) (process-children) ) (priority) ) Note: I am not so sure if my rule above is OK, I wrote it fast and did not made verifications. There is probably a better way to express it. However what is important to remember is that the rule should be structured as: (construction-rule-name pattern-matching-expression? action-construct-expression priority-expression?) (like Matthias suggested) That the query construction rule is fired as long as its priority-expression is bigger than zero. That the way to have a query executed only once if to change the priority-expression, for instance, in the action-construct-expression. If the action-construct-expression reset the priority-expression to zero, then on the next processing loop the rule won't be fired. But from your comment I do the following deductions: I have to include in the document: http://www.netfolder.com/DSSSL/MarkupRule.htm the following concepts: a) the construction rule processing loop b) update the generic construction rule to Matthias' description (see above) c) tell more on the query construction rule, the processing loop and the firing process of a query rule based on the priority-expression set to zero (not fired) or bigger than zero (fired). Also, if more than one query expression is present in a style-specification-body element then they are ordered on their priority number and all query construction rules sorted by the priority-expression. Their scheduling is based on this priority-expression (the biggest numbers first). Call for help: I would like to still keep the sgml-parse query-expression but would like to provide as example a better rule than the one I included in this message. Any suggestion for a clean rule? I'll include it in the document as an example of a query construction rule. regards Didier PH Martin mailto:martind@xxxxxxxxxxxxx http://www.netfolder.com DSSSList info and archive: http://www.mulberrytech.com/dsssl/dssslist
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: About Constructions rules, Peter Nilsson | Thread | Re: About Constructions rules, Matthias Clasen |
Jade core dumps on Solaris, Bob Wysong | Date | RE: Jade core dumps on Solaris, Avi Kivity |
Month |