Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Message-ID: <20000713131928.19869.qmail@web6202.mail.yahoo.com>
Date: Thu, 13 Jul 2000 06:19:28 -0700 (PDT)
From: Giacomo Pati <pati_giacomo@yahoo.com>
Reply-To: giacomo.pati@pwr.ch
Subject: Re: Behaviour of mount element in sitemap
To: cocoon-dev@xml.apache.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii


--- Stefano Mazzocchi <stefano@apache.org> wrote:
> Giacomo Pati wrote:
> > 
> > --- Stefano Mazzocchi <stefano@apache.org> wrote:
> > > Ross Burton wrote:
> > > >
> > > > >Now my question: is this 2. snipped correct?
> > > >
> > > > >If it is correct, then we need a way to manipulate the uri of the request
> > > > when delegating to
> > > > >sub-sitemaps to strip away the prefix of the parent sitemap. Or we have to
> > > > pass the requested uri
> > > > >separately to sitemap components (and thus changing several Interfaces).
> > > >
> > > > IMHO, this is right.  Sub-sitemaps only need to know about their portion of
> > > > the URI space and need no other knowledge (such as where they are mounted).
> > >
> > > Totally agreed. Just follow the Servlet 2.2 context mapping model.
> > 
> > Do you mean, that a SitemapProcessor should expose some kind of Resolver interface to make the
> > sub-sitemap have resolved any filesystem resource needed to the base of the mounted sitemap
> (some
> > kind of chroot behaviour)?
> 
> No, the sitemaps writers should have _no_ notion of where their sitemaps
> will end up being mapped.

Yes, aggree. I havn't intended that a sitemap maintainer needs to know where his sitemap is
mounted in the uri space. It was more a implementational thought as that SitemapProcessors
(concrete objects) are linked in a hierarchy to have URIs resolved bottom up. This because only a
parent SitemapProcessor knows the base (or a part of it) of a sub SitemapProcessor so that the sub
SitemapProcessor asks his parent to resolve URIs.

> The implementation should just enforce this in whatever way we (you, at
> this time) find appropriate.
>  
> > And what about links? Should a SitemapProcessor plug itself into the pipeline as a transformer
> and
> > intercept links to change them according to the "context" it runs in? Puh, this sound like
> > something I've removed some days ago which was called LinkTranslator, do you remember?
> 
> Hmmm, good point.
> 
> We should introduce the notion of "absolute" addresses.... hmmmm, what
> about
> 
>  1) <map:redirect-to uri="blah"/>
>  2) <map:redirect-to resource="blah"/>
>  3) <map:redirect-to location="blah"/>
> 
> where
> 
>  1) [uri] -> http://host/blah
>  2) [resource] -> local sitemap resource (should be inlined in the
> sitemap generation or called as a method call)
>  3) [location] -> redirected to the ./blah location of this very
> sitemap.
> 
> So, we keep the attribute "uri" for absolute resources and "location"
> for local resources.
> 
> What do you think?

It's ok for me.
I wish we had a simple table showing which element can have which attribute (and their meaning).
The sitemap XSchema might be good for automatic validation but it's not suitable for human reading
:(

Giacomo

=====
--
PWR GmbH, Organisation & Entwicklung      Tel:   +41 (0)1 856 2202
Giacomo Pati, CTO/CEO                     Fax:   +41 (0)1 856 2201
Hintereichenstrasse 7                     Mailto:Giacomo.Pati@pwr.ch
CH-8166 Niederweningen                    Web:   http://www.pwr.ch

__________________________________________________
Do You Yahoo!?
Get Yahoo! Mail � Free email you can access from anywhere!
http://mail.yahoo.com/