On Saturday, Sep 20, 2003, at 23:59 Europe/Rome, Sylvain Wallez wrote:
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 [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.
yes, this is still the main concern.
We now have to decide what meaningful information we place at these locations and RDDL was made just for this.
I doesn't really matter, as we are starting, what ends up being in that location. For example, take a look at
http://www.w3.org/1999/XSL/Transform
(the XSLT namespace URI), not even the W3C knows what to put there yet ;-)
[I didn't know that those URI were actually usable as URLs, it was something that came out from the discussion at www-tag]
I don't understand the reason for #2. Why don't we include "block" ?
I'm afraid of the collision between the "namespaces" used in the block realm and the "block id". It's just basic URI managing practices, but I wouldn't want people to think that
http://apache.org/cocoon/block/cob/1.0
is a block, while
http://apache.org/cocoon/block/pdf/1.0
is a namespace
It would be nice if the prefix
http://apache.org/cocoon/block
would be used *ONLY* and exclusively for block IDs and never for namespaces.
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.
this is exactly my point.
But I can also have missed something as I'm a bit swamped and have to catch up on the "Implementing Cocoon blocks" thread...
no worries.
Practical point : can the Cocoon team put something behind http://apache.org/cocoon/ ? We should ask infrastucture@
yes. I was thinking that we could host those things into
http://cocoon.apache.org/namespaces/cocoon/*
[note the "cocoon" subdirectory that would allow subprojects to have their namespace declarations there as well]
and have
http://apache.org/cocoon/
do some transparent URI rewriting over that. I think we already have the ability to do this, if we ask infrastructure@ to create a /cocoon/ directory over www.apache.org and use .htaccess to configure mod_rewrite.
thoughts?
-- Stefano.
