Return-Path: 
 <cocoon-dev-return-13538-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 48175 invoked by uid 500); 20 May 2001 18:02:22 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 48159 invoked from network); 20 May 2001 18:02:18 -0000
Date: Sun, 20 May 2001 20:00:23 +0200
To: giacomo <giacomo@apache.org>
Cc: cocoon-dev@xml.apache.org
Subject: Re: [c2] simple question on map:redirect-to semantics
Message-ID: <20010520200023.A1989@funny.localnet>
References: <20010519101035.A30518@funny.localnet>
 <Pine.LNX.4.31.0105191702520.1711-100000@lap1.otego.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
In-Reply-To: <Pine.LNX.4.31.0105191702520.1711-100000@lap1.otego.com>;
 from giacomo@apache.org on Sat, May 19, 2001 at 05:30:52PM +0200
From: Martin Man <Martin.Man@seznam.cz>
Sender: Martin Man <martin@funny.localnet>
X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N

On Sat, May 19, 2001 at 05:30:52PM +0200, giacomo wrote:
> 
> 
> On Sat, 19 May 2001, Martin Man wrote:
> 
<snip/>
> 
> Ok, lets nail it down. What is the semantic of the <map:redirect-to>
> element?
> 
> a) you can use the resource="resource-name" attribute to break out of
>    the evaluation sequence into a predefined pipeline arragement.
> b) you can use the uri="another-uri" attribute to let the environment
>    decide how to handle it by using the redirect method a concrete
>    Environment has to implement for the sitemap.
> 
> Now, a) is in the concern of the sitemap while b) is in the concern of
> the environment. The term uri is something that I don't like very much
> because if you imagine you have written a concrete Environment for lets
> say Apache James (Java Apache Mail Enterprise Server) what is the
> semantic of the uri= attribute there. Is it a bounce to say "this
> address isn't in use anymore, please use the address ${uri}"? Or is it
> forwarding the message to the address mentioned in the uri attribute?
> And what sense does it makes naming this attribute "uri" in a
> JamesEnvironment. But since I've no good alternative for an other name
> better suited to abstract that meaning of the uri attribute lets keep it
> as it is.
> 
> Speaking so we need to define how the concrete HttpEnvironment
> interprets the string specified in the uri attribute for different
> contexts the system is in.
> 
>                root-sitemap  sub-sitemap      sub-sub-sitemap
> uri: foo/bar   /ctx/foo/bar  /ctx/sub/foo/bar /ctx/sub1/sub2/foo/bar
> uri: /foo/bar  /ctx/foo/bar  /ctx/foo/bar     /ctx/foo/bar
> uri: //foo/bar /foo/bar      /foo/bar         /foo/bar
> 
> A question remaining is "how do I specify in the sub-sub-sitemap a uri
> for the sub-sitemap". Well either with ../foo/bar or with /sub1/foo/bar.
> 
> I don't like using a already used protocol specifier like context://
> because it already has a semantic like "pointing into the file system
> structure at the Environments root contexts". Using it in the uri
> attribute will change that semantic "pointing into the uri space
> structure at the Environments root uri space".
that's true and I don't like context:// here neither, but I think we can agree
upon that /sub1/foo/bar is useless (ok, not completely :-)) (it breaks 
the context independency) and ../foo/bar is too awkward to be universal
cure...

so what then ?
> 
> Comments?
> 
> Giacomo
> 

martin
-- 
-------------------------------------------------------------------------------
"Only dead fish swims with a stream"
gpg_key_available: http://globales.cz/~mman/martin.man.gpg
gpg_key_fingerprint: 2CC0 4AF6 92DA 5CBF 5F09  7BCB 6202 7024 6E06 0223

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org