RE: About Constructions rules

["Didier PH Martin" <martind@xxxxxxxxxxxxx>]

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