Saxon

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

No, I'm not prepared to make changes to ReceivingContentHandler to achieve this: it's not an important enough requirement to justify changes to this critical class. (And it's the kind of functionality that one really regrets adding four releases downstream when the design has changed.) I suggest you subclass RCH to achieve the required behaviour, and create a SAXTransformerFactory that generates a serializer containing your subclass.

Legacy ID: #4572448 Legacy Poster: Andrew Fang (afang4)

Unfortunately there is no easy way to subclass RCH as the change involve a private method "flush()". The proposed changes involve recognizing the escaping PI and set flag accordingly in flush() method. It looks like we have to either maintain our own change or fall back to xalan's implementation, which does honor the escaping PIs. Thanks for your help.

Legacy ID: #4582145 Legacy Poster: Paul Grosso (pgrosso)

It would be really nice to be able to upgrade from saxon 6.5 to 8.9, but we can't do that if disable-output-escaping stops working. And as Andrew explained above, we cannot solve the problem by subclassing RCH. Mike, at http://osdir.com/ml/text.xml.saxon.help/2005-05/msg00100.html you pointed out to a user that their problem was that they "switched from a ContentHandler that understands and implements disable-output-escaping to one that doesn't." It seems that's what happens when switching from saxon 6.5 to 8.9. This seems to be the last issue with our switching from 6.5 to 8.9. Is there any chance you would reconsider adding support for the d-o-e PIs to maintain compatibility between 6.5 and 8.9? paul

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

OK, I've implemented it. It won't be on by default; you will have to do TransformerFactoryImpl tf = new TransformerFactoryImpl(); tf.setAttribute(FeatureKeys.USE_PI_DISABLE_OUTPUT_ESCAPING, Boolean.TRUE); This means that applications that might currently be writing these PIs to a DOM (or to a Saxon tree) will continue to do so. Michael Kay http://www.saxonica.com/

Legacy ID: #4584717 Legacy Poster: Andrew Fang (afang4)

Thanks a lot!!

Legacy ID: #4606547 Legacy Poster: Andrew Fang (afang4)

Michael, I downloaded 9.0, but the disable output escaping PI does not seem to work. I did set the FeatureKeys.USE_PI_DISABLE_OUTPUT_ESCAPING attribute. It seems to me that in the following code in RCH, the escapingDisabled value should be set prior to calling flush(). if (allowDisableOutputEscaping) { if (name.equals(Result.PI_DISABLE_OUTPUT_ESCAPING)) { flush(); escapingDisabled = true; return; } else if (name.equals(Result.PI_ENABLE_OUTPUT_ESCAPING)) { flush(); escapingDisabled = false; return; } }

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

Well, the code passed my tests, and the logic looks right to me. Actually looking at it again the calls on flush() are redundant, because that's the first thing the processingInstruction() method does - and it clearly makes sense to flush the pending text before you set the switch, because you don't want to disable escaping for the text that was put into the buffer before the PI came along. My only slight reservation about the logic is that flush() is setting the WHOLE_TEXT_NODE flag, which is telling the recipient that they aren't going to receive adjacent text nodes, which isn't actually the case if one of these PIs comes along. But WHOLE_TEXT_NODE only matters if you are building a TinyTree, which you presumably are not. How are you running it, in particular what have you got downstream on the pipeline? Michael Kay http://www.saxonica.com/

Legacy ID: #4608998 Legacy Poster: Andrew Fang (afang4)

Thanks for looking into it. It works for me now, I was setting the attribute to a wrong transformer factory. There are two transformer factory in our pipeline, one for transformation one for serialization. Andrew