Saxon

Legacy ID: #2875215 Legacy Poster: Michael Kay (mhkay)

I'm a little puzzled by the requirement because I thought XML was a subset of SGML, but I guess you know what you are doing... You might find your solution more portable if you write it as a SAX ContentHandler rather than as a Saxon Receiver. On the other hand, it will be easier to reuse code in the existing Saxon serializer if you define it as a subclass of say XMLEmitter or HTMLEmitter. You can nominate either a Receiver or a ContentHandler as the destination for Saxon result trees. Note also that any attributes on the xsl:output element in your own private namespace will be accessible to your serialization code ifyou write it as a Receiver. This provides an easy way to parameterize your serializer. Apart from that I can't really suggest anything that you won't get from a study of the existing source code. Michael Kay

Legacy ID: #2875550 Legacy Poster: pdupin (pdupin)

Michael, Thank you for your very useful answer. The SAX ContentHandler solution is really better, and seems to suit well with my problematic, which is to process heavy SGML files with rules. Because of a lack of native solutions, I transform SGML to XML before, I apply XSL rules, and finally, I must transform XML to SGML. Because I'm a newbie, all advises are welcome... Thanks a lot.

Legacy ID: #2876188 Legacy Poster: James Francis Cerra (quantum_jim)

Note that SGML has its own (complicated) transform language called DSSSL, which may be more suitable to your situation.