Re: About Constructions rules

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