cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Derbyshire <>
Subject Re: Another showstopper in Xalan. No workaround seems possible.
Date Thu, 25 May 2000 21:47:29 GMT
At 09:50 AM 5/25/00 +0100, you wrote:
>The 'bug' you describe, which I'm not convinced is a bug at all (Xalan
>is generally very good at standards compliance) is absolutely nothing
>whatsoever to do with Cocoon. If you could join the Xalan mailing list
>and report it to the guys there, you stand some chance of getting a
>fix for it.

What Xalan mailing list? I searched your Web site up and down, and there's
no xalan-users list to be seen. Moreover, if I email (or xalan-users-request) I get "user
unknown". The only Xalan mailing list I can find any hint of is the one for
developers, which I'm not.

>Cocoon and Xalan are *OPEN SOURCE*. You did not pay for them, you
>decided to use them. They came with no guaruntees that they would
>solve your problems.

They came with strong statements to the effect that they supported the
*full* XML/XSLT standards,
and this inability to inline documents in other documents when I've heard
repeatedly this is a capability of XML, strongly implies that these strong
statements were wrong.

> 1) There's a 'bug' in Xalan. If that's the case, report it to
>    the relavent people, and they'll fix it as soon as possible.

And how do I do that? Nobody has deigned to provide a xalan-users list to
get feedback from end-users of Xalan. Then again, I get the distinct
impression that open source developers rarely think about end-users, and
think only of the development team, nine times out of ten, with the
apparent exception of the Cocoon development team.

> 2) There's something screwy in the way you're trying to do
>    things.

I did it exactly the way the tutorial described. Check out the links I
provided, particularly the foil67.html one. That one contains exactly what
I did: <xsl:apply-templates select="document($somevar)"\> with somevar
pointing to
an XML file.

>In any case, coming onto the *Cocoon* users list and declaring
>Cocoon and Xalan the 'doom' of your project...

I didn't make any such declaration. I lamented that I'm now unsure
*whether* it is the salvation or the doom of my project. Obviously you
didn't even read my post completely and clearly before deciding to launch
all missiles. Hothead.

> us fix them. We are not gods...

I can't hire anyone, on this budget. I could try to do it myself, if I had
enough spare time to learn all of the APIs and all of the internals of
Xalan, which I don't. Isn't Xalan 1.0.1 supposed to be a *finished
product*? I should not be encountering error messages that basically say
"This feature is not yet implemented. Sorry for wasting your download time
or claiming to be complete or claiming the technology is now mature enough
for production use. Try again next year, and the year after that, and
maybe, just maybe, you'll be able to finish your project by the year 2010."

>What *is* the WOL? Some of us here are software engineers by trade.
>If you tell us exactly what you're trying to achieve, we *might*
>be able to suggest a decent work around or even a new way of
>thinking about the whole problem.

An XML-enabled Web site. With some documents using links that are meant to
actually embed one document in another, or a data set in a document. The
idea being the XSL template for the embedding tag reads in the document
using document() and then runs it through processing; the style sheet for
the embedding document formats into HTML both the embedding document and
the embedded document or data, which allows the same document to appear
with different formatting or style in different embedded uses as well as as
a stand-alone document. All stuff XML and XSLT are supposedly capable of
doing. That foil67.html link shows a tutorial based on the XSLT
Recommendation and XPath Recommendation explaining how to do this. If it's
based on the W3C Recommendations, it can't be *wrong*, so either it is
*lying*! or there is a bug/"not yet implemented" in Xalan that shouldn't be

Phase 1 is just to compile the XML source locally to HTML which is then
uploaded to a Web server. (A account, as a matter of fact.)
Currently it seems easiest to use Xalan for this, since Cocoon AFAIK
doesn't support an API to call individual transformations from inside
another Java app, and I need another Java app (written, tested, and working
except for the Xalan problem) to traverse the directory structure
incrementally updating changed files. (I'd much rather avoid having to
explicitly run some app with a bunch of parameters every time I changed an
XML file; easier to make many changes throughout the XML sources tree, then
when these are finalized run a program that automates updating the HTML

Phase 2 is to set up my own Web server, using Apache and Cocoon, and
dispense with the compiling step. That can't work until I have a cablemodem
or other broadband access that can support a Web server's network
requirements and will be visible to the Linux operating system. And that
requires waiting for an improvement in the financial situation here. A
student can't easily afford either a cable-modem or cable ISP rates. (The
only alternative is free, unlimited space hosting with XML support e.g.
with Cocoon, and AFAIK there is no such thing. Besides which that has the
undesirable effect of meaning I can't test things locally and upload the
changes when they are debugged; instead I'd have to upload every change to
some remote, perhaps intermittently wonky server somewhere, *then* test
them, and the test/debug/edit cycle would slow to an unacceptable crawl.
Imagine having to upload and the download something over the net to fix
each single error in an XSL file! It simply isn't practical.)

   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  |
_____________________ ____|________                          Paul Derbyshire
Programmer & Humanist|ICQ: 10423848|

View raw message