cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ulrich Mayring <>
Subject Re: XML Query language
Date Thu, 17 Feb 2000 01:30:18 GMT
Stefano Mazzocchi wrote:

> You are welcome.. just, please, don't say you are bound to Cocoon, its
> not fair.

It's a sort of compliment, I think. If there were something better than
cocoon, then no-one would feel bound :)

In any case, while I don't understand most of what you guys discussed,
one thing stuck: I agree that it *is* evil to put anything
cocoon-specific in an XML file. Or, to generalize: XML files should
contain data, not instructions for an application, be it cocoon, a web
server or whatever. The data should drive the application, not the other
way around.

So, when I look at my XML files, I find these lines:

<?cocoon-process type="xslt"?>
<?xml-stylesheet href="test.xsp" type="text/xsl"?>

We are basically telling cocoon what to do with this XML file (in this
case apply an XSP transform). As far as I understand the sitemap, it
will allow us to put these instructions into a seperate file. Doesn't
that solve the whole problem? A single file to manage (or one per
directory if we like) and clean XML files.

If we want to get rid of cocoon now, we can. Our XML files are usable in
any context, because they contain only data and no workflow. Now let's
look at my XSP file "test.xsp":

<xsl:processing-instruction name="cocoon-process">type="xsp"</xsl:processing-instruction>
<xsl:processing-instruction name="cocoon-process">type="xslt"</xsl:processing-instruction>
<xsl:processing-instruction name="xml-stylesheet">href="test.xsl" type="text/xsl"</xsl:processing-instruction>

Again, more of the same thing, only in different syntax (why??). We want
to put this information in the sitemap, too. Too confusing this way.

On to the XSL stylesheet, referred to above by "test.xsl": Ah, cool, the
stylesheet (being the last node in the chain) contains nothing related
to processing. So I could re-use the stylesheet in a non-cocoon workflow
- isn't that great? The XSP file is a lost cause, of course, because it
contains Java code and other peculiarities. On the other hand, XSP is a
part of cocoon and if I am careful not to put any data in my XSP files,
but only processing instructions, then I should be fine.

I may be a bit naive (and certainly quite ignorant), but where exactly
is the problem now? :)


Ulrich Mayring
DENIC eG, software development

View raw message