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 [EMAIL PROTECTED], 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 http://apache.org/cocoon/blocks/*** namespace uri with http://apache.org/cocoon/*** and keep http://apache.org/cocoon/blocks/*** 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 http://apache.org/cocoon/ ? We should ask infrastucture@
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
