cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: RFC-2396 (Was: Re: [RT] composition vs. inheritance in blocks)
Date Mon, 04 Apr 2005 15:26:03 GMT
Pier Fumagalli wrote:

> On 31 Mar 2005, at 01:26, Stefano Mazzocchi wrote:
>>  block:super://blah.xml
> A very simple remark, I don't want to criticise...
> I'm already slightly "upset" about the "cocoon://" protocol, as it 
> does not follow the URI RFC properly, I'd like to address the problem 
> as early as possible...

> I wrote a small "rant" while on the plane, just to explain my 
> reasoning, with a couple of code examples, as it's (I don't think) 
> mailing-list material, I've stored it on my WIKI...
> Anyhow, feel free to discuss it here...

I read your rant and agree with it, it seem benefical to take advantage 
of I'm not completely happy with letting relative sitemap 
paths be opaque and absolute be hierarchical, but I don't see any better 



it is AFAICS a correct opaque URI. But we could make better use of if we considered a hierarchial URI scheme for blocks 
instead. From this perspective the scheme that Reinhard suggested makes 


for refering to the absoute path "/foo" within the portal block,


for refering to the absolute path "/foo" within the current block and


for refering to the relative path "bar" relative to the current 
(sub)sitemap within the current block and


for refering to the absolute path "foo" whithin the super block of the 
current and possibly


for refering to the relative path "bar" relative to the current 
(sub)sitemap within the super block of the current.

The last three URIs are opaque and could be resolved to absolute 
hierarchical URIs with a similar algorithm as you proposed for 
"cocoon:./" resolution.

Maybe using "//portal" as an authority is stretching the intepretation 
to far.

Using an URIs like the ones above has the advantage that we can reuse 
most of the definition of hierarchial URIs and the functionality in, if we instead go for the opaque style exemplified by 
"block:super://blah.xml" we have to define the URI parsing ourselves 

                                              --- o0o ---

As all URI discussions tend to provoke strong feelings for Stefano, it's 
best to say directly that this question is not important enough for me 
to fight about ;)

But anyway, whether we go for an opaque custom protocol or base the 
block protocol on hierachial URIs we need to get into the specifics for 
the block URI scheme to be able to implement it.



View raw message