cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: Blocks URIs
Date Sun, 21 Sep 2003 16:46:25 GMT
Stefano Mazzocchi wrote:

>
> 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 
>>> www-tag@w3.org, 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



Mime
View raw message