Why not just add a parameter which removes them or not, big deal. No reason for Yet Another Class.
-Andy On 6/2/03 9:34 AM, "Geoff Howard" <[EMAIL PROTECTED]> wrote: > At 08:57 AM 6/2/2003, you wrote: > >>> Seem not convinced? HTMLserializer that generates wrong output does not >>> convince the programmer? I mean, I can understand, if there is nobody >>> who has time or the capabilities to solve this bug, but not beeing >>> convinced sounds a little strange to me. >>> >> >> Don't tell me, tell the xalan babes: >> >> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19933 >> >> And read that last comment: even the W3C seems to think that HTML >> documents should contain the namespaces. > > <quote-from-wiki> > So... what I ended up doing was extending the HTMLSerializer (or whatever > serializer you're using for your pipelines), and overriding the > startPrefixMapping and endPrefixMapping methods to do nothing, effectively > removing all namespaces from my HTML. This also had the added benefit of > having no performance penalties (and theoretically, a ever-so-slight > speedup since we no longer process namespaces in our serializer). > </quote-from-wiki> > > I have done exactly this before -- does this still work from a purely > technical perspective? If so, why wouldn't we just define an > NoNsHTMLSerializer which extends HTMLSerializer and overrides > just those two methods? Then, it's a user decision whether these > namespaces belong > in real-world html. > > Geoff Howard > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
