Subject: RE: About Constructions rules From: "Didier PH Martin" <martind@xxxxxxxxxxxxx> Date: Thu, 15 Jul 1999 07:48:43 -0400 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: About Constructions rules, Brandon Ibach | Thread | Re: About Constructions rules, Brandon Ibach |
RE: About Constructions rules, Peter Nilsson | Date | RE: DSSSL engine in LISP? (also Re:, Didier PH Martin |
Month |