Return-Path: <stefano@apache.org>
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 55555 invoked from network); 5 Jan 2000 10:45:44 -0000
Received: from pop.systemy.it (194.20.140.28)
  by 63.211.145.10 with SMTP; 5 Jan 2000 10:45:44 -0000
Received: from apache.org (pv47-pri.systemy.it [194.21.255.47]) by
 pop.systemy.it (8.8.8/8.8.3) with ESMTP id LAA27007 for
 <cocoon-dev@xml.apache.org>; Wed, 5 Jan 2000 11:44:17 +0100
Message-ID: <3871259E.186DCBA2@apache.org>
Date: Mon, 03 Jan 2000 23:41:34 +0100
From: Stefano Mazzocchi <stefano@apache.org>
Organization: Apache Software Foundation
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en,it
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: Sitemap and Links...
References: <00d101bf5632$451ac8c0$c2a842d4@lab>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Luis Faus wrote:
> 
> Hi everyone!
> 
> I have been reading for the last days all your proposal for the new sitemap.
> I find the current state of Cocoon very exciting and i do like very much the
> initial sitemap proposal from Stefano. Anyway, these are my humble
> suggestions about the last days stuff;
> 
> > <sitemap>
> >  <!-- Slight twist on the conventional way -->
> >  <prefix uri="flowers">
> >    <process uri="*.html" translate="/home/xml/*.xml">
> >      <producer name="file" />
> >      <processor name="xslt">
> >        <param name="stylesheet" value="flowers.xsl" />
> >      </processor>
> >      <serializer name="html" />
> >    </process>
> >
> >    <process uri="xsp/*.html" translate="/home/xml/*.xsp">
> >      <producer name="xsp" />
> >      <processor name="xslt">
> >        <param name="stylesheet" value="flowers.xsl" />
> >      </processor>
> >      <serializer name="html" />
> >    </process>
> >  </prefix>
> >
> >
> >  <!-- More flexibility - assign processors to the prefix -->
> >  <prefix uri="diamonds">
> >    <processor name="xslt">
> >      <param name="stylesheet" value="diamonds.xsl" />
> >    </processor>
> >
> >
> >    <process uri="diamonds/*.html" translate="/home/xml/*.xml">
> >      <producer name="file" />
> >    </process>
> >
> >
> >    <process uri="diamonds/xsp/*.html" translate="/home/xml/*.xsp">
> >      <producer name="xsp" />
> >    </process>
> >
> >
> >    <serializer name="html" />
> >  </prefix>
> ></sitemap>
> 
> I think this proposal has still too much verbosity. What about this one?:
> 
> --------------------
> <sitemap>
> 
> <macro name="foo">
>     <process uri="*.html" translate="*.xml">
>       <producer name="file" />
>     </process>
> 
>     <process uri="xsp/*.html" translate="*.xsp">
>       <producer name="xsp" />
>     </process>
> 
>     <serializer name="html" />
> </macro>
> 
> <process uri="flowers/*" translate="/home/xml/*" macro="foo">
>       <processor name="xslt">
>         <param name="stylesheet" value="flowers.xsl" />
>       </processor>
> </prefix>
> 
> <process uri="diamonds/*" translate="/home/xml/*" macro="foo">
>       <processor name="xslt">
>         <param name="stylesheet" value="flowers.xsl" />
>       </processor>
> </prefix>
> 
> </sitemap>
> -------------------

Hmmmm, your sitemap is not well-formed. Do you mean <process or <prefix?
 
> Here a macro is just a set of instructions that any 'process' tag can call
> (inherit). Macros should be able to inherit from other macros.

Please, let's consider this: XML inheritance reduces verbosity but
increases complexity. Also, there is no standard/complete way to do XML
inheritance between different files (like I suggested) or in between the
same file (like Donald and you suggest).

But I think we should concentrate on having the sitemap complete on its
funtionality side before reducing verbosity with inheritance.

> A macro also can do some translation like in this example:
> 
> "flowers/index.html" gets translated to "flowers" + "index.html"
> "index.html" gets translated by the macro 'foo' into "index.xml", which is
> the value used in the replacement instruction, giving us
> "/home/xml/index.xml".
> 
> Do I make any sense?

I got your point, but you underestimate the complexity of a working
solution, along with the tree merging logic that is necessary.
 
> I think this way we would get _much_ smaller sitemaps, since we could take
> benefit of patterns in the sitemap design of the site.

True. XML inheritance is something that is worth investigating, but this
effort must be well separated or we'll never end the sitemap definition.
 
> Another thing I miss in the sitemap proposal is some support for virtual
> hosts. Since the sitemap is going to take control of all the translation
> process i think it should also take care of virtualhosts, or at least have
> some support for them (diferrent files for different vhosts) or some
> mechanism that avoids the need of one diferent cocoon and JVM for each
> virtual host.

No. No way. Cocoon is a servlet, servlets are considered web-apps. The
Servlet API mandate that a servlet can be mapped to one and only one
servlet context, otherwise, LOTS of concurrenty problems come out.

Trust me, you do not want Cocoon to handle virtual hosts.
 
> Well, that's all I found...

Thank you for your comments, they were brilliant ones.

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