Subject: RE: About Constructions rules From: "Didier PH Martin" <martind@xxxxxxxxxxxxx> Date: Mon, 19 Jul 1999 08:35:37 -0400 |
Hi Brandon, Back from my bike ride, and can answer to you now. Brandon said: 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? Didier says; To be appended to the actual output flow objects stream Brandon said: Where would you attach it to the output? At the end of the flow object stream. Or more precisely added to the flow objects already inserted in the flow objects stream. Brandon said: 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. Didier says: Like you said, the destination stream is unique. All created flow objects are appended to the flow object stream. My proposition is to keep is that way. There is no necessary need that a flow object generator to be connected to a single source document. It could be possible to have multiple sources but a single output. Brandon said: 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". Didier says: No the transform part do not allow multiple flow object sources. It only modify the source grove structure. The idea is to have more than one source grove to build a single output flow object stream. Brandon said: 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. :) Didier says: This is what we are studying also. We are documenting and understanding different part of our heritage: Jade. OpenJade could become what we decide it can become and then grove management is part of what we can modify. For instance, for some constructs, garbage collection could be improved. Let say for example, that you create a node list with sgml-parse("<url>http://www.metfolder.com/mydoc.sgml") and process this node list with (process-node-list) then when the whole list is processed, the garbage collector should release the memory taken by the node list when the whole list has been processed. This is some area where we have to improve OpenJade. And don't worry, I am already familiar with the details :-). Thanks for the example you provided for the query construction rule. 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: About Constructions rules, Didier PH Martin | Date | Re: OpenJade News - July 8 1999, Joerg Wittenberger |
Month |