Return-Path: <lfaus@derecho.org>
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Delivered-To: mailing list cocoon-dev@xml.apache.org
Delivered-To: moderator for cocoon-dev@xml.apache.org
Received: (qmail 41354 invoked from network); 3 Jan 2000 21:34:40 -0000
Received: from unknown (HELO lix.intercom.es) (root@212.66.160.2)
  by 63.211.145.10 with SMTP; 3 Jan 2000 21:34:40 -0000
Received: from lab (iv1-194.intercom.es [212.66.168.194]) by lix.intercom.es
 (8.7.3/8.6.12) with SMTP id WAA32585 for <cocoon-dev@xml.apache.org>;
 Mon, 3 Jan 2000 22:37:15 +0100
Message-ID: <00d101bf5632$451ac8c0$c2a842d4@lab>
From: "Luis Faus" <lfaus@derecho.org>
To: <cocoon-dev@xml.apache.org>
Subject: Re: Sitemap and Links...
Date: Mon, 3 Jan 2000 21:44:24 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211

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

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.

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 think this way we would get _much_ smaller sitemaps, since we could take
benefit of patterns in the sitemap design of the site.

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.

Well, that's all I found...

  Angel.

**************************************
Angel Faus - afaus@derecho.org
Derecho.Org
**************************************