cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <>
Subject Re: [finally!] The "Infamous" Cocoon Sitemap Proposal
Date Fri, 31 Dec 1999 10:35:08 GMT
On 31/12/99 at 12:52 am, (Stefano Mazzocchi) wrote:

>Jeremy Quinn wrote:
>> 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?

Er, well yes actually. I am building something like this at the moment, I just
happen to be static rendering it.

>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.

Sorry to say this .... I do get your point, but you may have to accept that
other people's idea of a good or bad design, may differ from your own. ;-)

If it is just a case of one particular site structure better suiting the way
Cocoon's sitemap works more than another one, then that's fine .... but we had
better make it very clear otherwise people will criticize sitemap functionality
rather than their idea for how they want their site laid out.

>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.

Would you like to suggest an alternative sitemap or site structure to deal with
IMHO the relativly common situation outlined above, where you need many
different XMLs rendered through several different XSLs?

>3) a good sitemap grows step-wise logarithmically with the web site size.

Yes, I agree, this is the ideal scenario.

>4) Cocoon is _not_ designed for small sites. 

I agree that the main effort is and should be towards managing large complex
sites, but it will get used for small sites, the advantages are obvious ;-)

>> 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
> <cocoon>
>  <global>
>   <root os="dos">c:/web/</root>
>   <root os="unix">/home/www/</root>
>  </global>
> ...
> </cocoon>
>so that you can mount your stuff in the URI space as you do in the real
>file system space. What do you think?

So, you saying that the <root> becomes the prefix for "translate" paths and/or
filepaths? That is fair enough I guess. Only one thing to change when you move
the map to a different machine or OS. It might be nice to have the option to
have the <root> set automatically to the WebServer Root as happens now?
(Hardcoded full file paths are considered really bad news in MacOS, because at
the moment, there are few standard directories and no standard volume names.
This will probably change with MacOS 10) 

>> At what stage in the rendering process does the link re-writing intervene?
>We are not sure about that.

I don't think I have fully grasped the link re-writing proposal.
I need to read through it all again.

This is all getting rather interesting ;-)




      Jeremy Quinn                                             media.demon
                                                           webSpace Design
     <>       <>
      <phone:+44.[0].207.737.6831>          <>

View raw message