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 ;-)
;-) Yeah. That's not an important point to get started, but it would to define what _should_ be put there, to allow people (or tools) to get some minimal information about a block without having to download it first.
[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.
Mmmh... a good structuration of namespace URIs would require block-defined namespaces to be in a block-related area of the URI space such as "the http://apache.org/cocoon/block/";. But then we conflict with block IDs.
So what about the following convention :
- http://apache.org/cocoon/block-id/pdf/1.0 for the pdf block _identifier_
- http://apache.org/cocoon/block/pdf/foo/1.0 for the "foo" namespace of the pdf block ?
By using different "block-id" and "block" URI sub-spaces, we avoid the naming conflict. And using different sub-spaces makes sense IMO since they're not used to identify the same kind of information.
<snip>
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.
That would be great.
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
