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 Fri, 31 Dec 1999 13:22:43 GMT
Jeremy Quinn wrote:
> 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
> >> 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.

Sorry, I should see your XML before talking. I take this back.

> >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
> >opinions:
> >
> >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. ;-)

Oh, totally. One of the most religious things in computer science is
file system look. I happened to place all my code under "c:\code" and my
programs under "c:\Program Files". I also try to reduce the number of
root directories to a minimum, unlike others.

There is no algorithmical way to understand if a file system space or a
URI space is better or worse.

The sitemap length might give you a way to "measure" the beauty of your
solution, as much as your stylesheet complexity will measure the beauty
of your DTD.

True, this is not an absolute value, but gives you contraints. Also,
there are infinite numbers of URI space partitions that require the same
sitemap complexity. The old math problem of finding the minimum will
generate (hopefully) design patterns that allow us to understand how to
write better URI spaces (as well as better DTDs).

But this is new ground, we are the first explorers of this land.
> 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.

Oh, yes, Cocoon already does force you to think in a particular way.
Powerful, elegant, but particular and different from standard way. URI
space design will have the same forces, but will hopefully allow you to
create design patterns so that your URI space partition is "portable".

Think about it: you write a very complex web-app for a customer and then
you "reuse" the URI partitioning design patterns over to another similar
web-app, reusing much of your code, DTD and configurations.

Today, URI partioning is a black art. I want to help engineering it.
Cocoon wants to engineer what today is an art... in an artistic way :)
> >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?

No, you got me wrong, I was concerned about extracting several contexts
of information from the same source file. But, again, this is rather
pointless without a better knowledge of the problem space. No, I don't
have a better suggestion.
> >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 ;-)

This means: the power increase Cocoon will give you is proportional to
the site size. But still higher than zero for small sites, even if
significantly lower than for big sites.
> >> 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
> >welcome)
> >
> > <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? 

Yes, something like that.

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

Sure, if you don't specify anything it will work that way (as it
currently does).

> (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 ;-)

No kidding.

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