I am afraid it's not going to be that simple. First the dom4j project
seems pretty dead to me, there hasn't been any cvs activity for almost a
year now. Second, even if the bug was fixed, it's not sure we will be
able to upgrade dom4j for the reasons dicussed in these issues:
http://jira.codehaus.org/browse/MAVEN-1345
http://jira.codehaus.org/browse/JAXEN-67
http://issues.apache.org/jira/browse/JELLY-226
If someone familiar with dom4j/jaxen would like to have a look at that
problem, he is very welcome to do so... :)
-Lukas
Wayne Fay 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]
