Well someone found the source/location of the bug, so that's a good first step.
I guess I'm an eternal optimist. ;-) Wayne On 3/1/06, Arnaud HERITIER <[EMAIL PROTECTED]> wrote: > This bug was open in august and isn't yet fixed. I'm not sure that the dom4j > team is really active. > Furthermore, we already tried to upgrade ours dom4j dependencies but we > didn't succeed. > > Arnaud > > > On 3/1/06, Wayne Fay <[EMAIL PROTECTED]> wrote: > > > > Great news. > > > > Can you please keep an eye on this issue and report back when its > > fixed? Then we can update poms to get the new dom4j, and finally put > > this issue to rest. ;-) > > > > Wayne > > > > > > On 3/1/06, Lance Bader <[EMAIL PROTECTED]> wrote: > > > Remember this issue? Someone has found the location of the > > defect. See Bugs > > > item #1277785. > > > > > > > > http://sourceforge.net/tracker/index.php?func=detail&aid=1277785&group_id=16035&atid=116035 > > > > > > Maybe we will some some action on this. > > > > > > Lance > > > > > > On 12/8/05, Lukas Theussl <[EMAIL PROTECTED]> wrote: > > > > > > > > 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] > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
