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 Sun, 28 May 2000 07:13:18 GMT
At 11:22 AM 5/27/00 +0100, you wrote:
>I would tend to avoid using document() for this purpose. In my opinion,
>document() is a slightly dodgy construct at the best of times.

But the tutorial pretty much asserts that that is precisely the job it was
intended to address. Are you saying that whoever wrote the standard botched
something up? Isn't that unheard-of?

>Much better to use XInclude if you possibly can. I can't see anything
above can't
>be done either by judicious use of conditional processing - redirecting
>the document to different stylesheets (much easier in Cocoon2, I must
>admit) or in the case of the article with data, XIncluding the data into
>a node in the article.

>Remember that you can <xsl:import/> the a data
>stylesheet into the article stylesheet.

Yeah, but that would require making everything that might be included in
anything a *stylesheet*, which seems like (yet another) ugly hack to me.
I'd have no documents -- just stylesheets! Plus I want templates to do
things like
import a parameter document and enclose it in a frame box (made with a CSS2
span element or with a table), and
move its title above the box, and other fancy stuff. I'd have to repeat
those instructions manually all over the
place using <xsl:import/>. 

Meanwhile, there is this XInclude thing (and I've also been hearing things
about XLink?) -- the trouble here
is twofold:

* The list headings contain stuff like "XInclude processor should be fixed"
followed by lots of replies and
  lots of posts with titles like "XInclude question", all of this implying
that it's *not* fixed, or at the very
  least is dodgy enough to be doing unexpected things and baffling people.
I'd rather avoid using something that
  confusing if I possibly can. It doesn't sound like it beats out
document() in any case.
* If I'm not mistaken this XInclude thing is a *Cocoon* feature, and is not
available with stand-alone Xalan.
  But Cocoon doesn't appear to present a public process() type API the way
Xalan does, so my batch converter
  would have to repeatedly system() the thing, once for every file, which
  - Recursive JVM invocations -- I don't know how the system will tolerate
that, especially given how much memory
    a JVM allocates. What if the Cocoon invocation's Java heap grows huge
-- I could end up with massive swapping
    or sporadic OutOfMemoryErrors depending on how the Java sessions divvy
up the available memory. I.e., it
    is liable to be slow and it might not be reliable. FYI, the available
memory is 256M, 64 physical.
  - Repeated JVM invocations -- a JVM startup for every file in the batch
is liable to be slow and tedious.
    I'd rather avoid that.
  The alternative would be to try invoking the Cocoon.main() method
directly from my app, but:
  - It's YAUH (Yet Another Ugly Hack) -- jesus christ, we now need an
acronym for this term, it's cropping up
    so frequently in XML-land!
  - I don't know whether the special semantics Java has for the main()
method would cause unexpected problems to
    arise (such as e.g. the JVM shutting down when the first Cocoon
invocation exits!) -- at least it is a
    public method, if they'd required it to have a private signature or
something it couldn't even be tried.
  Either of these means getting the 1.7.5 snapshot and coaxing it to
actually work. (Recall the troubles I had
  trying to coax 1.7.4 to work -- that's what prompted them to start on
version 1.7.5! -- and trying to coax
  Xalan to work.) If it is humanly possible I'd like to get this working
with Xalan alone, and migrate to full-on
  Cocoon for phase 2 or somewhere in between...once I've got some kind of a
foot in the door on this thing.

>The conditional processing is, I admit, a pain in the backside in
>Cocoon1.x. Basically how you achieve it is to run the XML through
>an XSP logicsheet that produces the required processing instructions
>for what you're requesting.

Good grief, yet another XYZ technology to learn. Sounds like the scenic
route to what I'm trying to achieve to me.
At least XInclude is probably just a single new tag to learn, and then
probably equivalent to the <embed/> I was
trying to make work.

>The other option would be to have a set
>of .xml files that have the processing instructions in them, and then
>just xinclude the origional document fragment. Slightly kludgy, but
>probably less kludgy than using document() to do the same thing.

If the tutorials are to be believed document() is supposed to be
straightforward and not kludgy...

>Heh. Totally ageree - you're preaching to someone who wrote a custom
>templating engine for *ONE* project (in the years before cocoon) that
>was nearly as powerful as Cocoon is now, just to avoid writing the
>same code over and over and having to run three line regexps over it
>to fix stuff afterwards ;)

I was just about to do the same thing when I stumbled onto DocProc while
researching XML -- it seemed likely
to be able to do what I needed (but couldn't: it refused to output markup!
It acted like it was in text output mode rather than HTML, regardless of
the <xsl:output/> tag's attributes and regardless of command line switches.
Investigating the possibility of other programs like DocProc, I discovered
Cocoon and Xalan and the like.

Thing is, I get the impression from what I've learned that I'm sitting on a
goldmine and the nearby mining supply shop in town is fresh out of
pickaxes. If and when I get this thing actually working at phase 2, if some
of the experiences people have reported here are to be believed, the Web
site with its obvious use of Java technology and a Powered By Cocoon button
will cause IT departments and e-business thatare hiring to beat a path to
my door, and my financial situation can be expected to seriously improve...
of course if the site proves interesting and useful enough to people a
relatively unobtrusive sprinkling of ad banners could be equally lucrative.
But, like most people poking about at open source things, my main interest
is just to get the thing going, prove it can be done, and put something
useful on the net. That's why the site would be free. As for what exactly
it would be doing -- why, starting off a quantum leap in the evolution of
the web, by using XML to its full potential to deliver a complex
interconnected knowledge base on some subject or another. In fact, the
subject is likely to be ecology, so the site would represent the
interconnection of life on earth, a tool that might be sorely needed if
environmental problems continue the way they are. Right now ecological
types just have a few glimpses of the full structure of the world's
ecology; they have the food web fairly well mapped but not the assortment
of symbioses and more complex interrelations. Most of what humanity knows
about life on earth is scattered in disconnected fragments in assorted
research journals, not combined into a single resource that could, with
enough people contributing, grow into a road map of sorts, an atlas of
ecology that would help those doing restoration or
repopulation-of-threatened-species projects find their way and avoid
pitfalls (like the notorious trash pine "reforestation" of the 50s).

>Everyone here is very very much on the right side of this line. We're
>all engineers, not hackers.

Arguably, anyone who sees a need for a computer tool and proceeds to write
it, particularly an open-source one, is a hacker in the original meaning of
the term.

>Anyway, I *hope* the above has given you some food for thought.
>I *think* I've understood what you were saying right. If not,
>then give us more information and we'll try, but no promises,
>we've got other people to help and other lives to lead.

Well there's more information above, on the issues that will obtain under
various circumstances, but now I'll need more information, particularly
about this XInclude and XSP stuff, and about the production-readiness or
lack thereof of XInclude support in Cocoon (or perhaps Xalan).
   .*.  "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