The reason for the default HTML mapping rules in Tika are to simplify and normalize the input documents so that client applications could easily process all sorts of input (HTML or not) without needing type- or source-specific heuristics. The basic idea has been that clients should directly use the underlying parser libraries when it needs custom processing of specific content types.
That said, I see the value of being able to process even complex HTML input through the Tika API, and perhaps the above original intent is too strict for many use cases. The HtmlMapper interface we added for
TIKA-347 should make it possible to relax the mapping rules, and in revision 933909 I added a IdentityHtmlMapper implementation of this interface to make it even easier to use:
ParseContext context = new ParseContext();
Note that IdentityHtmlMapper breaks the guarantee that the Tika output is valid XHTML. Also, currently the HtmlMapper interface only covers elements, so all attributes are still lost and IdentityHtmlMapper overrides the custom <a/> tag handling in HtmlHandler so even the href attributes are gone. It would be good if we could extend the HtmlMapper mechanism to avoid these problems.