cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Bastardized URL protocol
Date Thu, 13 Nov 2003 12:29:41 GMT
On 12 Nov 2003, at 17:18, Berin Loritsch wrote:

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

Now, we introduced the ** syntax for matchers and I think it was one of 
the greatest innovations in easy-to-use path-oriented query syntaxes, 
althought non standard. Nobody ever complained and I don't think it's 
because they are too shy to tell us.

At the same time I agree that




don't feel exactly as elegant. Actually




would be better, IMO, but would be totally back-incompatible at this 
point, so it's hard to change this syntax now.

The problem I see with your proposal is that xml:base doesn't really 
solve anything: we need to be able to differentiate between

  path -> relative to current sitemap

  path -> relative to root sitemap

this discrimination has the granularity of the single cocoon:/context: 
call, it's not global. The only potential solution I see is something 

  <generate src="cocoon:/path" xml:base="/">
  <generate src="cocoon:/path" xml:base=".">

but I don't think xml:base works for this. An alternative is

  <generate src="cocoon:/path" relative-to="/">
  <generate src="cocoon:/path" relative-to=".">

which would allow to do

  <pipeline relative-to="./path">
   <match ...>
    <generate src="cocoon:/blah"/>

that would be equivalent to what today is

    <generate src="cocoon:/path/blah"/>

but I'm not sure this makes things any easier or bugs any more evident. 
For sure, it's more verbose and for back compatibility, we still need 
to support cocoon://



View raw message