RE: About Constructions rules

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