RE: About Constructions rules

Subject: RE: About Constructions rules
From: "Didier PH Martin" <martind@xxxxxxxxxxxxx>
Date: Thu, 15 Jul 1999 09:59:07 -0400
Hi Peter,

Peter said:
There have been some discussion about the semantics of the
query-construction-rule. Brandon Ibach and Frank A Christoph explained
this and the processing of nodes well, so I won't do anything about it.

As Mathias Clasen siad, what I wanted to point out was that sgml-document
node returned in Dieder PH Martins example would never be processed.
Ofcourse, this is clearly stated in the specification and IMHO there is
nothing open for "interpretation" here.

I haven't read many standards at all, but I learned one thing. They are
not written to be easy to read and one have to read them very carefully
taking every word into account. Indoubtedly there are errors in the spec,
but in general I find it very well written (but I'm no expert on how
standards should be written...)

Sory if I have a "teaching attitude", but I think we have to be very
careful when we say that something is not specified and go out in fantasy
land.

Didier says:
I agree, but we have to prepare DSSSL-2, do not forget it. And we have also
to improve OpenJade and if possible provide powerful new features that could
help the community.

So, in a previous post, I mentioned that the whole point is:
a) do the query construction rule is strictly behaving as: the result of the
query-expression is compared to the current-node and if there is a match,
then the rule content-expression is fired.
b) the query construction rule is not necessarily based on a pattern
matching process. Instead, the construct-expression is executed if the
query-expression returns a non null node-list and if the priority-expression
is a the right level for this execution context (last item is same as for
(a) ).

There is a sentence in the specs saying:

"Each construction-rule matches some (possibly empty) set of the nodes in a
source grove."

So, this sentence do not mention (without exceptions). But I think that it
indicated that the original intents was that all rules are based on pattern
matching.

So, let's imagine for a moment that we no longer look behind but in front of
us and that in front of us there is a new spec to write. let's call it
DSSSL-2. In this context:
a) the query construction rule is not part of Jade or OpenJade and therefore
we do not have feedback from concrete implementations to help us decide if
it is good "as is" or need some improvements. The original specs where done
with the best knowledge of that time, but we learned a lot since then.
b) because it is not implemented we can implement it but this time with some
knowledge gained with years of experiences.

Still looking in front of us, imagine now this scenario. A guy crazy enough
to give free time to his colleagues wants to implement a new feature: the
query construction rule. This guy learned from his colleges, listened to
them, their needs, the limitations of actual constructs, etc... In fact,
there is actually several crazy enough people with names like Avi, Matthias,
Dave, Peter that think that things could be improved and improve them!

Now, let's think of this scenario:
a) the query construction rule could behave like DSSSL-1 stated, this means
that the result of the query-expression is matched to the current-node and
if matched, the rest of rule is executed.
b) the query construction rule is not matched against the current-node. This
implies that if the query-expression returns a non empty node-list, the rule
is fired if the node-list is not empty (and the priority set to the right
execution context), otherwise the rule is not fired.

Now a productive question is: independently of any specs or past written
words. What is more useful. What leads to more useful scripts. What leads to
more easily learned constructs, What could simplify DSSSL scripts, etc... In
simple words, do some thinking.

So, the question is no so more: Is this strictly in accordance to the specs,
but what is more useful. and if a construct is found more useful, then let's
modify the future spec to reflect the experience gained.

This said, I agree that the sentence: "Each construction-rule matches some
(possibly empty) set of the nodes in a source grove". Set that it was in the
editors intents that the query construction rule is also pattern matched.
Now, not to break the specs, should we create a new construct to include
functionalities stated in (b)? Could we just use the lack of (without
exception) expression to change the query construction rule behavior? Should
we instead, crate a new construction rule and keep this one as is?

But before coding anything:
Is the query construction rule useful? If yes, can we provide a sample of
its usefulness with a concrete script (not executable in any DSSSL engine
but could give the idea of its usefulness). Or without having to write a
script, could we imagine some usages and discuss them? In one word, learn if
construct (a) is more useful than (b). The goal is not to be lemmings, the
goal is to create a well thought DSSSL and have a great implementation
OpenJade.

Peter, thanks for your comments, we progress...So now, in which context do
you see or envision the query construction rule with a pattern match
behavior. Do you have a concrete example in mind?

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


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


Current Thread