Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 12011 invoked from network); 12 Nov 2003 21:18:15 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 12 Nov 2003 21:18:15 -0000 Received: (qmail 88962 invoked by uid 500); 12 Nov 2003 21:17:59 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 88936 invoked by uid 500); 12 Nov 2003 21:17:59 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 88923 invoked from network); 12 Nov 2003 21:17:59 -0000 Received: from unknown (HELO onramp.i95.net) (205.177.132.17) by daedalus.apache.org with SMTP; 12 Nov 2003 21:17:59 -0000 Received: from apache.org ([66.208.12.130]) by onramp.i95.net (8.12.10/8.12.9) with ESMTP id hACLI393029019 for ; Wed, 12 Nov 2003 16:18:03 -0500 Message-ID: <3FB25D3C.30808@apache.org> Date: Wed, 12 Nov 2003 16:18:04 +0000 From: Berin Loritsch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: Bastardized URL protocol (Re: [RT] ComponentizedProcessor) References: <84F0A43A4248CE45B5C0E20F4C40779C667CA4@naomi.webworks.nl> <3FB21271.6070805@apache.org> <33497.10.0.0.5.1068657379.squirrel@ags01.agsoftware.dnsalias.com> <3FB22637.3080401@apache.org> <6CD3FA44-154E-11D8-A27B-000393D2CB02@apache.org> In-Reply-To: <6CD3FA44-154E-11D8-A27B-000393D2CB02@apache.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Stefano Mazzocchi wrote: > > Variable scoping aside, do you have any suggestion on how to solve the > protocol issue? > > -- > Stefano, who reached a point where rants look like a very inefficient > way of solving problems As I mentioned in another email, leverage the xml:base="" attribute part of the XML spec. That provides the base URI with which all relative URIs would be resolved. It's dead simple, obvious, and less error prone than one slash vs. two. Best of all, we don't bastardize any specs. The point of my "yawn" example is that braindead mistakes happen. It's best to make it really obvious what the problem can be.