Subject: RE: About multiple output documents from a single XML/SGML processed document From: "Didier PH Martin" <martind@xxxxxxxxxxxxx> Date: Thu, 12 Aug 1999 08:35:49 -0400 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: About multiple output documents, Didier PH Martin | Thread | RE: About multiple output documents, Frank A. Christoph |
RE: About multiple output documents, Didier PH Martin | Date | Pass parameter to Jade?, Kai Großjohann |
Month |