Subject: Re: About Constructions rules From: Brandon Ibach <bibach@xxxxxxxxxxxxxx> Date: Mon, 19 Jul 1999 13:17:16 -0500 |
Hi Didier, Pardon me for reformatting here, but I think it will make it easier for me to respond. Quoting Didier PH Martin <martind@xxxxxxxxxxxxx>: > Quoting Brandon Ibach <bibach@xxxxxxxxxxxxxx>: > > 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? > > To be appended to the actual output flow objects stream > > > 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. > 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? > > 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. > > 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. > I didn't mean that we had to tie to just one source grove, I just meant that the context within the source grove provided an implicit destination for the output of a rule. You can accomplish the same with multiple source groves, but if a rule isn't tied to a place within *some* source grove, then you won't know where to put its result. > > 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". > > > 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. > 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. 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. 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. 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. -Brandon :) DSSSList info and archive: http://www.mulberrytech.com/dsssl/dssslist
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: About Constructions rules, Didier PH Martin | Thread | RE: About Constructions rules, Didier PH Martin |
Re: DSSSL engine in LISP?, Joe English | Date | Re: (commercial) applications using, Steffen Heinrich |
Month |