Sry for the delay. Shall I commit the StripNameSpaceTransformer to trunk/core/cocoon-pipeline/cocoon-pipeline-components/...../transformation , or is there a more preferable location? Should I also add it to the branch?
Ard > > > > > 1) The lightweight StripNameSpaceTransformer ... Add > > > this to trunk/branch or not? > > If no objections, I'll add my version of the > StripNameSpaceTransformer to the trunk/branch on short notice > > > > > +1 > > > > > 2) The XHTML serializer: Make it by default strip the list of > > > namespaces we know people don't want to sent to the browser. > > > > -1 No, please don't. If you have a browser that does not understand > > XHTML (like IE) don't feed it with XHTML! It's as simple like > > that. If > > it understands XHTML it also must be able to handle namespace > > declarations and additional XML-specific attributes like > xml:space or > > xml:lang. Do you want to suppress them as well? > > > > Such a behaviour might be valid for a HTMLSerializer though. But > > actually I don't care for that one when we have > > StripNameSpaceTransformer. > > > > > About serializers: Does anybody know why we have a > > serialization part > > > in cocoon core and one in a serializers block? Is it > > preferred to use > > > serializers from the serializers block? Normally, I am using > > > org.apache.cocoon.serialization.HTMLSerializer and configure > > > doctype-public. > > > > Those from core are Xalan's serializers at the end. Those from > > serializers block are own implementations from Cocoon once > > made by Pier. > > As Cocoon should not write serializer IMO I prefer the core ones. > > I agree on this one. > > > A > > better integration with Xalan community to get our wishes > applied to > > those serializers might be desirable (one issue was the > > closing of tags, > > which must not be closed or consist only of a start tag in > > HTML IIRC). > > This would make our own implementations superfluous. > > > > Jörg > > >
