cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett McLaughlin <bmcla...@algx.net>
Subject Re: Sitemap and Links...
Date Tue, 04 Jan 2000 16:16:19 GMT
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>
> -------------------

I don't like this.  The number of combinations and mappings that could
occur within a "macro" are nearly infinite.  One site could easily have
some URI that want to process XSP, some that want to process XML, some
that want to process both, some that want to process other formats...
the list gets very long, and you get a nice fat exponentual curve in the
number of macros that may need to be defined as supported processes
increase.  This to me forces you to either:

(1) you have to allow inclusion of multiple macros, which becomes
_really_ hairy.  Precedence?  Ordering? etc.
(2) you lose what "verbosity" you reduce in all the permutations of
macros you have to support.

In addition, I don't think there is that much verbosity.  Consider that
75% of that example was the "overly verbose" way and the last little bit
was the efficient way.  I also think having one URI's instructions in
one consolidated place is much better (Even with added verbosity) than
less verbosity and having to scroll up and down a large sitemap. 
Remember these are supposed to be easily maintainable, not neccessarily
really small files.

Have you ever read an XML schema where the type of an element was
specified about 100 lines away from the element definition?  I have, and
it _sucks_.  So I will give up some verbosity... plus I think the macro
idea has the problems I outlined above anyway...

-Brett

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

Mime
View raw message