RE: About Constructions rules

Subject: RE: About Constructions rules
From: "Frank A. Christoph" <christo@xxxxxxxxxxxxxxxxxx>
Date: Thu, 15 Jul 1999 14:00:17 +0900
Didier wrote:
> 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.

Huh? A query rule will only be "fired" if the current node is a member of
the result of the style-query-expression. (Let's call this "sqe" from now
on.) This is very clearly stated in the standard.

> 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.

I don't understand what you mean by "restrict". There are no restrictions on
the sqe except that the semantics of current-root and current-node are
changed in that context.

> 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.

That is very creative.... but the standard does not mention anything about
resetting anything. Furthermore, it is irrelevant when the sqe is evaluated,
since it does not depend on state of the grove traversal. The standard makes
sure of that, in fact, by locally altering the semantics of current-node.

I think the intended purpose of priorities is that when the current-node
matches more than one query rule, the rule with the highest priority is
preferred. This is stated in the discussion on "relative specificity" of
construction-rules in the standard.

> 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.

A better way to express it would be to use DSSSL. ;) Perhaps you meant:

(define priority 1)
(query (sgml-parse "<url>http://www.netfolder.com/doc.sgml";)
  (let ((priority 0)) (process-children))
  (priority))

Even if your interpretation of the standard were correct vis-a-vis queries,
this would yield an error for two reasons. First, priority was not defined
as a function, so you cannot call it. Second, DSSSL is, like Scheme,
(mostly) lexically scoped, so binding 0 to priority in the let expression is
useless since it is not mentioned in the body of the let. Even if it were
dynamically bound, and process-children ended up "firing" off this same rule
again, the "priority" identifier appearing in the priority-expression is not
in the scope of the process-children call, so it would not be
overriden/shadowed as you apparently intended.

> Matthias said:
> No, I think what Peter wanted to point out is that a query construction
> rule is "fired" for every node of the grove which is a member of the
> node-list
> returned by the query-expression. Your example involving sgml-parse isn't
> very useful, since sgml-parse returns a node-list, but none of
> the nodes is
> part of the current grove. Thus the rule will never be fired.
>
> Didier says:
> OK I see. That's a fourth interpretation.

I don't really think this is open to interpretation.

> In the case the
> requirements are:
> a) the query-expression is applied on the sgml-node and then on all its
> children
> b) the action-construct-expression is applied on the returned
> node-list from
> the query-expression
>
> this then implies that a query could only be applied to the
> source document.
> then off course sgml-parse would not be qualified as a query-expression.

The query rule is applied to the current node; if it matches, the
construct-expression is evaluated. If you could somehow get the root node of
the sgml-parse'd document to be the current node, then your query rule would
match, since it includes every node of the parse result. But it is not a
question of "what the rule is applied to" or whether or not the sqe
"qualifies". Any expression "qualifies"; if the expression doesn't yield a
node-list, it will raise an error. Otherwise, it will match the current-node
at some point or not.

> So, the spec by itself is either ambiguous or left to implementors.
>
> Actually I think that both rules could be applied and conform to
> the specs:
>
> a) a query-expression is applied to the source document and if the
> query-expression includes a current-node expression it is always
> associated
> to the current-root node. Thus, a query is applied on the whole source
> document.
>
> b) as long as the query-expression is valid and part of SDQL
> (sgml-parse is
> part of SDQL) and if the query-expression returns a node-list then the
> action-construct-expression acts on the node-list. If, in the
> query-expression a current-node expression is present, then this
> expression
> is equivalent to current-root and threfore the query is applied
> on the whole
> document.
>
> Because the specs do not provide additional information about the query
> context, then both (a) and (b) are valid. (b) do not restrict the
> existance
> of (a) and is then a superset of (a) (because it includes it).

I think your (b) is flawed. It is irrelevant whether the sqe is
syntactically composed of SDQL expressions or not. The standard says that an
sqe is syntactically any expression. The only thing that matters is what
sort of value it has when it is _evaluated_; in particular, it should
evaluate to a node-list.

--FC


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


Current Thread