It's a known issue: http://jira.codehaus.org/browse/MPXDOC-111
Nothing we can do about in xdoc, it's a dom4j bug. -Lukas Lance Bader wrote:
In HTML there are tags that are forbidden to have content or end tags, namely <area> <base> <basefont> <br> <col> <frame> <hr> <img> <input> <isindex> <link> <meta> <param> In XHTML, of course, everything needs an end tag, even if content is forbidden, and the xDoc plug-in correctly adds end tags while generating its XHTML output. However, it adds explicit end tags instead of using the unary format. For example, it expands <br> to <br></br> instead of the unary <br/>. Even if the XML source contains an explicit <br/>, the xDoc plug-in converts it to <br><br/>. For our project, it is important for our XHTML files to be reusable and we have adopted a number of standards, both industry standards and company standards, to assure that. Compliance testing is performed with Parasoft's WebKing application. I was dismayed to discover that WebKing, for these tags, considers an explicit end tag a violation of "industry web standards". It considers the unary format acceptable. I can see their point; an explicit end tag invites content between the start tag and the end tag and content is forbidden for these tags. If it was a perfect world, the xDoc plug-in would, either by default or by user configuration, use the unary format instead of explicit end tags for these tags. I would rather not encourage a permanent special case for our XHTML. Even a special post-build step to make the XHTML comply could cause unacceptable risk and effort. What do you think? Could the xDoc plug-in be enhanced? Should it be enhanced?
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
