we should improve the modularization of editors - no editor quirks should remain
in doctype modules or core xslts. to that end, each editor must implement its
own pre- and post-processing pipelines. pipeline views can be used to implement
that without requiring hooks in the publication sitemap.
in addition to the editor-specific post-processing of documents, richard frovarp
made a suggestion that i like quite a bit:

>> well, then just put the fck stuff there, too. but we should make a 
>> huge mental note that each editor module should do their own 
>> pre-processing and cleanup in the future...
>>
> 
> This is post-processing. I do see that kupu does its own pre-processing, 
> which I'm going to be copying part of for fck. What is needed is for the 
> editors to do their own post-processing and include a global 
> post-processing file, such as clean-xhtml.xsl. All of the editor don't 
> have anything to lose converting i to em for example. No need to 
> replicate that step 4 or more times.

i.e. each editor should include a global (per doctype? needs some thought) xslt.
if a user wants to set a global XHTML policy, like discouraging <i> in favour of
<em> or <strong> in favor of <b>, s/he can declare it just once and be done with it.