cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [finally!] The "Infamous" Cocoon Sitemap Proposal
Date Thu, 30 Dec 1999 23:52:30 GMT
Jeremy Quinn wrote:
> On 29/12/99 at 4:07 pm, (Pierpaolo Fumagalli) wrote:
> >> I must admit, it will take me a while to understand fully .....
> >
> >IT's not that difficult, the basic idea is that Cocoon now behaves more
> >like a web server, handling all requests for a specified path. The best
> >place to understand how this works is the Servlet 2.2 specification, in
> >the "web application" part.
> So, let me try a simple example .... :)
> I have a set of XML files, for which I need multiple html pages to populate a frameset.
Let's say I want three frames, one for texts, one for a list of references to people, one
for a list of links. All from the same XML file.

Do you really want to do something like that?
> <sitemap>
>   <process uri="text/*.xml" translate="/home/www/sources/*.xml">
>     <producer name="file"/>
>     <filter name="xslt">
>       <param name="stylesheet" value="/home/www/text.xsl"/>
>     </filter>
>     <serializer name="html"/>
>   </process>
>   <process uri="people/*.xml" translate="/home/www/sources/*.xml">
>     <producer name="file"/>
>     <filter name="xslt">
>       <param name="stylesheet" value="/home/www/people.xsl"/>
>     </filter>
>     <serializer name="html"/>
>   </process>
>   <process uri="links/*.xml" translate="/home/www/sources/*.xml">
>     <producer name="file"/>
>     <filter name="xslt">
>       <param name="stylesheet" value="/home/www/links.xsl"/>
>     </filter>
>     <serializer name="html"/>
>   </process>
> </sitemap>
> My frameset could then contain the following links:
> This would be bloody marvelous ....
> A tad verbose though ;)

The hardest thing for me to accept the sitemap idea was its intrinsic
verbosity. But I thought _a_lot_ about it and found a couple of solid

1) badly designed web sites will lead to verbose sitemaps, on the
contrary, well designed web sites will need less verbose sitemaps.

2) sitemap complexity can be a direct measure of your web site
complexity and might lead to the creation of design patterns for sitemap
complexity reduction. Since I believe that verbosity reduction is
proportional to augmented readability and reduced management cost, I'd
rather have you spend your cycles in designing your URI space rather
than messing around with the sitemap.

3) a good sitemap grows step-wise logarithmically with the web site
size. This means that once you've reached the needed web-site
complexity, every addiction in the same patterns will not need to modify
the sitemap, or, if it does, produces redesign rather than simple
verbosity increasing.

4) Cocoon is _not_ designed for small sites. Small sites will have
complex sitemaps compared to other solutions. This is why I do not
recommend Cocoon for pure HTML replacement.

5) I assume sitemaps will be managed by learned people that keep control
of the "contracts" between the working contexts. This is the
"management" box in the "pyramid model of operation" (see Cocoon docs).
> One issue I see is that the examples all seem to rely on unix type (standard) file paths.
TBH I don't understand the nuances of Unix file paths, but it would be rotten to have to put
a full paths into the sitemap, when on MacOS for instance this would have to include the volume
name, not good for portability.
> Could Cocoon have the concept of a root folder to work from, or am I gloriously missing
the point ;-)

Yes. You'll have the ability to provide something like this (comments

   <root os="dos">c:/web/</root>
   <root os="unix">/home/www/</root>


so that you can mount your stuff in the URI space as you do in the real
file system space. What do you think?

> Plus, in your example of re-mapping file references, what would happen if you wanted
a link between two XML files to be relative, because they exist in different directories?
<link href="../../thing.xml">thing</link>.

If the link is "hard", it's left untouched. You link is "hard" since you
didn't say anything about it.

If the link is "soft", it will be rewritten and the relative information
used to access the resource. Then, the link will be replaced with the
location the resource takes after the transformation. Your relative
information in "soft" links is used only to access the resource, it's
doesn't mean anything after the remapping has taken place.
> Or in another situation .... I am using a site-wide link glossary, containing the actual
url references
> <links id="siteX">
>     <link id="hrc" type="full">
>         <ref></ref>
>         <title>The HyperMedia Research Centre</title>
>     </link>
>     <link id="blah" type="rel">
>         <ref>blah.xml</ref>
>     </link>
> </links>
> I then include stuff like <link idref="blah"/>,  <link idref="hrc"/>, <link
idref="hrc">alternative name</link> etc.
> Then use the XSL to look up the references.
> At what stage in the rendering process does the link re-writing intervene?

We are not sure about that.

I think the rewriting should take place "everywhere", the rewriting
engine being part of the transport SAX pipe from one stage to the next.
But we need more cycles in this since it could slow down the process

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche
 Come to the first official Apache Software Foundation Conference!  
------------------------- http://ApacheCon.Com ---------------------

View raw message