RE: About Constructions rules

["Didier PH Martin" <martind@xxxxxxxxxxxxx>]

Hi Brandon,

Brandon said:
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?

Didier says:
Brandon, you are right on this. I also think that, the original intent was
that the query-expression returns a node-list and this latter is compared
with the actual node-list being processed. If there is a match the rule is
fired. If the rule's priority is set to zero it is not fired. You made the
right inference by saying that this could leads to better mode processing.

By working on the interpretation I tried to:
a) understand the original intents because we do not have a reference
application to refer to.
b) stretch the specs by staying within what is said but interpreting them so
that we can maybe have something more powerful than originally envisioned.

For Point (a) I think that you stated it very well and most probably
reflected the original intents of the spec designers.
Now for point (b). I often take notes of what people say in the list. An
item that comes once in a while is batch processing for a collection of
documents. Let's imagine a scenario:
1) we create, for instance, a topic map document that implicitly contains
the notion of collection of resources. this topic map document (i.e. a SGML
document) contains a collection of SGML/XML documents. The DSSSL script is
applied to the topic map document process it.
2) instead of rendering the topic map document, the DSSSL script just
extract with queries the resources references, then process each returned
node-list with, like you said the (process-node-list) construct.
3) the process-node-list construct could be processed in a separate thread
of execution and then several queries could be run in parallel. No gains on
a single processor machine, but huge gains on a multiprocessor machine
because we do parallel processing.

So, the main processing loop process the source document. If a query refer
to an external document and creates a new grove, and that the query
construction rule contains a process-node-list instruction, then this list
is processed by a separate processing loop, but will use the actual script
rules. For instance, if the target document contains a <section> element
then if the script contains a (element section .....) this rule is fired. A
whole document collection could be processed this way.

Thus, the whole decision point is:
a) the query construction rule is like all the other construction rules. its
query-expression part is pattern matched to the source document current-node
b) the query construction rule is not necessarily pattern matched to the
source document current-node and its execution depends primarily on the
priority-expression. This implies that some construction rules could be used
to build node-lists and process them. Process part of the source document
based on an query-expression. In this last case, the query construction rule
is not fired by the result of a pattern match but by the returned node-list
from the query-expression. If the node-list is empty, then the
construct-rule is not executed, if it contains at least an element it is
fired.

I am exploring (b). option (a) is also interesting, but I take the occasion
to think about ways to process document collection. This could also
distinguish DSSSL by offering a powerful feature. The main research point
now is: Is (b) offering the same capabilities than (a).

Now the question is: could this be done within the actual specs spirit or
should this be added to the specs and more particularly incorporated in
DSSSL-2 with a different construct.

With this all said, I think that your interpretation is probably reflecting
the designers intentions. For the query construction rule, the
query-expression is checked for a match with the current-node, and if
matched and that the priority-expression has the right priority, then the
construct-expression part of the rule is then executed. So, in this case,
the query construction rule was created to have an pattern match expression
created at run time instead of being statically created like the element
construction rule.

I know that this reflection is not easy but Brandon, up to now, you didn't
seemed lost and followed the topic very well. I thank you for your well
taken comments. Do not forget that I have DSSSL-2 in mind, we can now
improve DSSSL. Also, if we can add a powerful feature to DSSSL, this could
be helpful for the community too.

regards
Didier PH Martin
mailto:martind@xxxxxxxxxxxxx
http://www.netfolder.com


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