RE: sgml-parse and GC

["Hennessy, Sean" <shennessy@xxxxxxxxxx>]

Didier says:
Ad contrario, this gives you something. Again, take the example where
you
want to process a collection of documents. All documents are included in
a
SGML/XML document as below:

<collection>
<document href="c:/mydir/mydoc1.sgm">
<document href="http://www.netfolder.com/mydoc2.xml";>
</collection>

Then, a DSSSL script process this source document and contain a rule to
process the document element as:

(element document
	(sgml-parse (attribute-string "href" (current-node))
	(process-node-list)
)

then, a thread can be set to process this new grove (as a autonomous
entity)
until the current-root and all its children is processed. For each
document
element we would have a separate grove and this grove processed in a
separate thread. This way, a batch job to processed a collection of
documents could be expressed as a SGML document itself instead of a
platform
dependent batch file.

Peter said:
If you want to process large documents and wanna be able to navigate
arbitrarily ghrough them (which DSSSL requires), then you will need a
lot
of memory... 

Sean whines..
Please consider the following..
1. Each <collection><document> may require a separate catalog.
2. There are performance issues associated with large collections.
<batch temporal='serial' model='SingleProcess'> vs <batch
temporal='parallel' model='MultiProcess'>
For example, should <document href="c:/mydir/mydoc1.sgm"> be able to 
reference elements of <document
href="http://www.netfolder.com/mydoc2.xml";>
then multi-thread/process implementations of sgml-parse will require
shared memory mechanisms as well?
The 'thread..to process this new grove..' mentioned above
hits this already hideous constraint with an asynchronous ugly stick!







 DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist