Subject: RE: About Constructions rules From: "Didier PH Martin" <martind@xxxxxxxxxxxxx> Date: Mon, 19 Jul 1999 21:01:36 -0400 |
Hi Brandon, Brandon said: One major problem here. The output of a style specification isn't a flow object *stream*, it's a flow object *tree*. Suppose the FOT that I've built so far has a s-p-s with three paragraphs as children. Would the result of the query rule be the next sibling after those 3 paras, or would it be a sibling of the s-p-s? Or, could it even be the last child of the last para? And what if I don't even want the output of the rule to be at the "end", whatever that is? For that matter, when would the query rule even be processed? Before I did all this other processing, after it, or somewhere in the middle? The DSSSL engine explicitly processes the root of the source grove. What would trigger the processing of this rule? Didier says: First about the query construction rule not attached to the source document. Thinking more about it, I think this should be a totally different construct (or simply classify it as a bad idea :-). However, by continuing my research I discovered that a SGML/XML document could be used to manage a collection of documents. Thus the need for a construct like I first showed is less important. Also, it may leads to certain bugs like you mentioned (and new ones I discovered later on). This is why I am modifying the document about the construction rules. Secondly, about the flow object tree. The overall structure could be said to be of a tree but locally (in the processing part of a rule) it is more like a sequence or stream. This is also why this is called a sosofo , sequence of.... I meant by stream the local operation not the whole output construction. So, for now I dig more on memory management and the way to process a collection of documents and we re-discovered all together why the query construction rule is in the specs and how it could be very important in a script and also, for which purpose. Now about collection of documents: A source XML/SGML document contains elements like for instance this: <Book> <chapter href="file://c:/myStorage/chapter1.xml">Introduction</chapter> .... </book> then have a DSSSL script with (element book (process-children) ) (element chapter) (process-node-list (sgml-parse (get-href(current-node))) ) get-href is a custom procedure to get the href value as a string (not added to the core function but more like all custom procedures included in scripts) I found that this construct do the job for collections. Let's call this the "pull model" the document is pulled in the output result by the source document. An other way to see it is to imagine that the script push the collection in the output result and this independently of the source document. The query construct is obviously not the right one. A better construct would be triggered only once and would not depend on a source document and would also include a construct to tell when it is fired so that its result can be inserted in the right place. But, such a rule could enter in conflict with other rules that are more "event based" or dependent on a source document. So, to make the story short, I have to think more about his and the idea was emitted prematurely. I do more thinking on this And also do some exploration on how other systems implement their rules (like balise, Omnimark). I already did this research, but need to do it again with different eyes. From this first reasearch on other systems I discovered for instance that XSL is having a main construction rule and this is a "query construction rule". It also has a query language called XPath. Our concerns about the implementation of the query construction rule could be reassured by the XSL implementations out there. Anyway, conclusion: I'll think more about the push model and now to insert at a precise point an external grove in the output result. Brandon said: Well, having since gone back and read through the TL spec a few times, I can better address this now. The transformation language *does* allow for multiple source groves (as an optional "feature"). I haven't sorted this out completely, but I believe it is always accomplished via the "auxiliary groves" feature. In any case, the transformation language does *not* modify the source grove. DSSSL *never* modifies the source grove. The transformation language builds one or more *result* groves from the one or more source groves. Didier says: Sorry I badly expressed myself this is what I was thinking but did not said it right. Anyway, in the transformation part of DSSSL, if we would modify the source grove the transformation rules wouldn't be operational anymore. So, we have to do the transformation from a source grove to a destination grove. Brandon said: Interestingly, the query construction rule in the style language very closely resembles an "association" in the transformation language. They both have a query part (what to process), and construction part (how to process), and a priority part (when to process, if you will). The difference is, the construction part in an association doesn't produce a SOSOFO. It produces (to simplify just a bit) a "transformation specification" which specifies not only how to transform the nodes, but also where to put the result. Any transformation spec can create a new result grove or attach its result to an existing result grove created by some other association. Didier says: I never made this inference and thank you for helping me make it. Yes indeed there is some analogy here. I'll read the specs again with this concept in mind, I will probably also discover something new in the process. Brandon said: In conclusion, while your idea for how to use query rules to pull in additional documents was an interesting approach, I think the way to do it is still to have a node in the grove whose processing (using (sgml-parse) and (process-node-list)) will result in the processing of the subdocument (be it the node which, directly or indirectly, has the name of the document, or just a placeholder), and process it at the right place to have its output land in the right place in the FOT. Didier says: I agree, it is easier that way to know where the result is located in the tree. Also, the scope of processing is easier to manage. When the process-node-list is finished with processing the list it can be released from memory. Thus, the source document help to structure the output and then provide the right sequence of action. Also, we keep the event based model clean and it is easier to understand. All rules are dependent from the source grove and all rules are triggered by the source grove. A concept easier to grasp. Brandon said; Good to hear that you guys are looking for ways to improve memory handling, especially when dealing with large documents and multiple groves. I think that will be important for making OpenJade robust enough to handle some real industrial-strength applications. Didier says: Yes, but it is a long process. Sometime when I look at the code I feel like an archeologist trying to find the intentions of a lost civilization :-) 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: sgml-parse and GC, Didier PH Martin | Date | Re: About Constructions rules, Brandon Ibach |
Month |