cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Blocks URIs
Date Sat, 20 Sep 2003 21:59:11 GMT
Stefano Mazzocchi wrote:

> I spent the afternoon cleaning up the block section in the wiki and, 
> after an interesting discussion I had with Tim Berners-Lee over at 
>, I was looking at the Block URI concept again and found 
> out that, as TimBL suggested in another context, the use of HTTP URI 
> might yield unforseen results.
> I proposed to deprecate the use of http: as URI scheme identifier for 
> the blocks because I wanted to remove the "direct dereferencing" 
> ability and wanted to introduce a lookup mechanism.
> As TimBL suggested while referencing to the XML namespaces that 
> include an HTTP URI, the ability to "directly look it up" is powerful. 
> And any non-dereferenciable URI (such as my proposed cob: scheme) is 
> simply another URN and the lookup machanism is just a reinvention of 
> what's already there.
> After careful thinking, I think he is totally right.
> So, regarding to this, I proposed the following changes:
>  1) substitute cob: with http:
>  2) substitute the*** namespace uri 
> with*** and keep 
>*** for block URI
> #2 is required for proper handling of dereferenced cocoon namespaces.
> What will be found at those block URI is yet to be decided, but having 
> the ability to do it is powerful and should not be thrown away.
> Comments?

Sounds good. The reason behind "cob:" instead of "http:" was that you 
did not want people to assume that it could be the download location of 
the block. We now have to decide what meaningful information we place at 
these locations and RDDL was made just for this.

I don't understand the reason for #2. Why don't we include "block" ? 
Furthermore, we already have a large number of namespaces for pipeline 
components, and there's a risk of conflict and/or confusion if we cannot 
distinguish easily block URIs from namespaces URIs.

But I can also have missed something as I'm a bit swamped and have to 
catch up on the "Implementing Cocoon blocks" thread...
Practical point : can the Cocoon team put something behind ? We should ask infrastucture@


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message