RE: About Constructions rules

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