cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Florian G. Haas" <f.g.h...@gmx.net>
Subject Repost: Failing miserably at nailing a suspected bug in Excalibur xmlutils or Cocoon TraxTransformer
Date Sat, 20 Sep 2003 19:55:05 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello again,

since the members of this list are usually remarkably quick in responding to 
issues, I presume that this one got a little lost in the recent OXF and 
release management discussions. Perhaps now someone can find a little time to 
look into this.

If this topic happens to have been covered previously, I'd be very grateful 
for any pointers.

Best regards and many thanks in advance,
Florian


- ----------  Forwarded Message  ----------

Subject: Failing miserably at nailing a suspected bug in Excalibur xmlutils or 
Cocoon TraxTransformer
Date: Thursday 18 September 2003 00:46
From: "Florian G. Haas" <f.g.haas@gmx.net>
To: dev@cocoon.apache.org

Hello,

since I recently introduced myself in my first post to the users list, which
 I suppose many of you are reading at least occasionally, here's the brief
 version: my name is Florian, I am currently using Cocoon in order to build
 web sites from XML topic maps, among other things.

For about three weeks now, I'm trying to dig up the reason for the behavior
described on August 30 in my post "2.1: Neither LinkSerializer nor
LinkGatherer producing a complete link list" to the users list.[1] Upayavira
provided lots of help and I have a hunch that the namespace-related issues
described in the thread really have nothing to do with the ExtendedXLinkPipe
as both he and I originally supposed, but that its due to a bug buried
somewhere in the Excalibur JAXP parser wrapper, the Cocoon TraxTransformer,
or a combination of both.

To illustrate the issue, I'll take a DocBook example. I'm quite certain that
most of you are familiar with DocBook XML 4.2, and with Norm Walsh's
docbook-xsl stylesheets. So for brevity's sake, I'll only post a source and
output code snippet.

Source DocBook XML (this is an excerpt of a document I've written to put on
 my personal web site):

<para>This entire process is automated using the <ulink
  url="http://cocoon.apache.org/2.1/index.html#What+is+Cocoon%3F">Cocoon XML
    publishing framework</ulink> brought to you courtesy of the <ulink
  url="http://cocoon.apache.org/">Apache Cocoon
      project</ulink>. Currently, I run Cocoon off-line (using the
  <ulink url="http://wiki.cocoondev.org/Wiki.jsp?page=CommandLine">Cocoon
    command line interface</ulink>), and upload the generated pages onto a
 web server serving static content.</para>

Here's the output when running Xalan 2.5.1 from the command line with the
unaltered XHTML style sheet from Norm's docbook-xsl package, version 1.62:

<p>This entire process is automated using the <a
href="http://cocoon.apache.org/2.1/index.html#What+is+Cocoon%3F"
target="_top">Cocoon XML
    publishing framework</a> brought to you courtesy of the <a
href="http://cocoon.apache.org/" target="_top">Apache Cocoon
      project</a>. Currently, I run Cocoon off-line (using the
  <a href="http://wiki.cocoondev.org/Wiki.jsp?page=CommandLine"
target="_top">Cocoon
    command line interface</a>), and upload the generated pages onto a web
    server serving static content.</p>

This is just what's expected. Now, here's the output when using the same
stylesheet in a simple Cocoon pipeline (file generator, xslt transformer
using Xalan 2.5.1, XHTML serializer)[2]:

<p>This entire process is automated using the <a ="" target="_top">Cocoon XML
    publishing framework</a> brought to you courtesy of the <a =""
target="_top">Apache Cocoon
      project</a>. Currently, I run Cocoon off-line (using the
  <a ="" target="_top">Cocoon
    command line interface</a>), and upload the generated pages onto a web
    server serving static content.</p>

Something is really not quite right here. What swallows the href attributes?
Not only their values, but also their names are empty -- strange IMHO,
particularly because this type of behavior seems to be limited to <a>
elements. I've run into a couple of other issues as well, e.g. xmlns
attributes on some elements where they aren't strictly necessary, but nothing
else as bad as this.

I've already spent hours debugging the transformation and serialization
process, but I've been unable to nail this apparent bug. Perhaps someone with
more TraxTransformer or Excalibur experience could look into it.

I haven't yet filed a bug on Bugzilla about this as I'm currently only
observing symptoms and can't even confirm whether it's a real issue. If I
should suspect it to be, I'd be grateful for a shove in the right direction
where to look closer. Currently I must confess I'm stuck.

Best regards,
Florian


[1] thread archived at:
http://www.mail-archive.com/users@cocoon.apache.org/msg02100.html

[2] My setup is a current Cocoon CVS checkout, J2 SDK 1.4.2_01, and Tomcat
4.1.24 for JDK 1.4 with the required XML-related jars in the endorsed
directory. The same files are also in jre/lib/endorsed in my JAVA_HOME.

- --
Florian G. Haas <f.g.haas@gmx.net>

GnuPG key ID: 0x46D00BE3
Key fingerprint: 18B4 3E7B 191E F534 254A  1F7C 816D 950B 46D0 0BE3

My GnuPG key is available from the public PGP key server at
pgp.mit.edu (and various other key servers).



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE/bLCkgW2VC0bQC+MRAv5sAKCYijlb251sW24VC4HLhetTjC8LjgCfWGpj
RaupR1key6ql99GecwUyFpk=
=Dava
-----END PGP SIGNATURE-----


Mime
View raw message