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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: About Constructions rules, Peter Nilsson | Thread | Re: About Constructions rules, Matthias Clasen |
(commercial) applications using DSS, Pieter Rijken | Date | RE: About Constructions rules, Didier PH Martin |
Month |