Re: About Constructions rules

[Brandon Ibach <bibach@xxxxxxxxxxxxxx>]

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