Subject: Re: About Constructions rules From: Brandon Ibach <bibach@xxxxxxxxxxxxxx> Date: Thu, 15 Jul 1999 12:01:49 -0500 |
Quoting Didier PH Martin <martind@xxxxxxxxxxxxx>: > 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. > I need to clarify something here. The priority of a query rule is never "set", it is only evaluated (as it is an expression), and should, technically, only be evaluated once, as it should not be able to contain any components which would cause it to be dependent on the state of processing. Furthermore, the only purpose of the priority expression is to resolve conflicts when a node appears in the "target" node list of more than one query rule. A priority of zero does *not* disable a query rule. In fact, query rules which don't specify a priority expression have their priority default to zero. Didier, I understand that you're looking for ways to expand the original spec (with the goal of creating a new one) in order to increase the power and flexibility of these constructs, but I'm concerned for two reasons. My first concern may be due to my not completely understanding what you have in mind, but the idea that you seem to be proposing of firing a query rule unconnected to any source grove node leads me to wonder, what would be done with the result of that rule? Where would you attach it to the output? How would the user specify that? The "destination" for output of rules is implicit in the context of the processing of the source grove. If you disconnect yourself from the source grove, there is no longer *any* mechanism to specify where your output goes. This brings me to my second concern, which has already been raised, at least somewhat, today. As I look at what you're attempting to do here, it occurs to me that the existing DSSSL standard may have a better answer: the transformation language. Not having looked at the spec for the TL for a while, I couldn't tell you right away what the mechanism would be, but I suspect that's where you'd find it, as the transformation language is all about "what to process, how to process it, and where to put the result". I find your batch-processing idea interesting, but I think we'd be better off equipping OpenJade with a proper batch mode, where it can handle resources (like the gobs of memory those groves must take) better. Doing it the way you describe, while it may seem elegant, could lead to major resource consumption problems, as Jade may be unable to effectively judge how long to keep each of those groves around, possibly resulting in huge amounts of memory usage. Somebody more familiar with the details of this sort of thing can feel free to correct my statements here, if I'm mistaken. :) Quoting Matthias Clasen <clasen@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>: > Quoting Didier PH Martin <martind@xxxxxxxxxxxxx>: > > I have now to find a good example showing that using a "query" > > construction is in some context is better than the "element" > > construction rule. I have to admit that I lack some imagination > > for the example and that some help would be appreciated. Does > > someone as any idea? > > Anything that requires you to process a node that is not of class element. > Thank you, Matthias! That was the piece that was missing for me in trying to come up with an example. Given this... Suppose you have a DTD which declares an "index" attribute which can be used in just about any inline element (such as elements that provide links, bolding or italics, or semantic distinction such as indicating an acronym). Without actually going into the code here (because I'd have to look a bunch of stuff up, and I've already spent too much time on email today :), you could create a query rule whose style-query-expression returned a node list containing every attribute-assignment node which defines the "index" attribute. If the contents of the attribute were the entry that should appear in the index (with a pointer to the location of the element with the attribute), you could use this as part of a mode to build your index. An element-match based rule would not have worked in this case (at least, not well), because the attribute can occur in a whole range of possibly unrelated elements. Also, if you ever changed your DTD to allow the index attribute in a new element, you'd have to change your stylesheet. With the query rule, this wouldn't be necessary. -Brandon :) DSSSList info and archive: http://www.mulberrytech.com/dsssl/dssslist
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: About Constructions rules, Didier PH Martin | Thread | RE: About Constructions rules, Didier PH Martin |
RE: The DSSSList Digest V3 #105, Didier PH Martin | Date | RE: (commercial) applications using, Didier PH Martin |
Month |