RE: About multiple output documents from a single XML/SGML processed document

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

Hi Avi,

Avi said:
I would rather not extend the dsssl model any more than necessary, as this
would probably involve modifying all backends and losing compatibility to
other dsssl engines. The simple solution exists today: run Jade once per
output file, with parametrized stylesheets. It could be optimized to use a
single invocation of the program, so as to minimize the parsing necessary,
but no more.

Something like

    jade -d 'xform1.dsl | (style1.dsl; style2.dsl; (xform2.dsl |
style3.dsl))' something.sgml

with some way to name output files (this example produces three output
files, two of them transformed once and styled once, and one file
transformed twice and styled once).

This is actually useful; I have a 10-pass stylesheet which produces around 5
output files in 3 different formats. Just looking at the makefile makes me
dizzy.

Didier says:
Yes this is an option but not as versatile as what's required to resolve a
problem like stated by a user in this group. With a rule based mechanism,
you have more versatility than with the command line.

Yes also, you are right to say that the impact is for all the backends.
However, if we limit the modification to a single object (i.e.
simple-page-sequence) the modification is a lot easier. Obviously each
backend treat file creation within their class. Luckily, they all tended to
follow the same model as the rtf backend. This, also greatly simplify the
modification process.

Finally, do not loose sight that we are now actively, preparing DSSSL-2
draft specifications. That DSSSL is not any more an interesting fossil but a
living organism and the next step is the new draft specification. This new
draft specification should not be a simple photocopy of DSSSL-1 but can and
preferable should include new improvements and not solely minor
specifications corrections.

In this spirit, we have here the opportunity to find a way to respond to a
concrete need expressed by some members of the user group and to provide a
concrete solution to a problem experimented and stated by a member of this
group. And which is, from a single SGML/XML document, to be able to produce
several output documents and this based on some elements. This output
creation is then, in that case, rule based.

The proposal on the table is for discussion, and from this discussion, we'll
end up with a reasonable construct that could satisfy the constraints
imposed  by the DSSSL-2 draft specifications. So, we are not limited by
DSSSL-1 specifications here.

However, to satisfy standard compliance, the Matthias' switch named "strict"
could be used so that the script is check in a DSSSL-1 compliance and any
deviation reported as an error. Also, the experimental addition, could be
under the "-2" mode so that it is made clear, until DSSSL-2 specification
acceptance by the international community that this is an experimental
construct. The advantage, is that the international community will also have
the opportunity to experiment the proposed new construct and the proposal to
be grounded on practical needs and experience. As long as we respect, the
DSSSL-2 draft specification constraints (should be SGML compliant,
consistency requirement, etc...) we are working constructively.

I know that this is hard to imagine progress and future when the ship gets
deserted by its officers but new hope and efforts have replaced a "no
future" world, and the boat still continue its course. So, now, keep in mind
that the new destination is DSSSL-2 and that new features could (and
preferably should) be included. However, instead of adding anything on paper
without concrete experience or adding something not necessarily grounded in
people's needs or in problems to be solved leads to a useless specification.
We won't do this kind of mistake and we will take the huge opportunity to
listen to peoples needs, suggestions, discuss openly about DSSSL future and,
as much as possible, construct the DSSSL-2 specs from this.

This said, Avi, I'll study the impacts of your proposal with the actual
source code.

I take note that actually, we have two poles:
a) a DSSSL-2 perspective and rule based mechanism. This needs modification
of the backend, the wisdom would be to limit the modification to a single
flow object (i.e. simple-page-sequence, because page sequence is not yet
implemented).
b) an actual implementation modification without any DSSSL-2 perspective.
This solution, requires a command line modification.

Solution (b), if it is easy to implement, may be a short term solution, but
I am still interested to continue the process of thinking of what to add to
the DSSSL-2 drafts. I have a notebook full of ideas. But, as a good engineer
it is better if the solution and ideas gets grounded in people needs and
that we address these needs in the next DSSSL-2 specs. This way, the specs
will be there to serve the people and not the contrary.


Avi, thanks for your input (and also for all the efforts you put in
OpenJade - there is a bad tendency in our modern societies to say what's bad
not to say some simple words like: thank you. So let me tell you: thank you
for all the work you do in OpenJade).

regards
Didier PH Martin
mailto:martind@xxxxxxxxxxxxx
http://www.netfolder.com


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