You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2003/09/20 19:27:25 UTC
Blocks URIs
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?
--
Stefano.
Re: Blocks URIs
Posted by Gianugo Rabellino <gi...@apache.org>.
Stefano Mazzocchi wrote:
>>
>>
>> Since the block id should be a resolvable URL, why not
>> http://cocoon.apache.org/blocks/pdf/1.0 ?
>>
>> This way, it's difficult to confuse it with the namespace and we don't
>> need any rewrites on apache.org.
>
>
> D'oh! you are so right. +1
+1 too.
/me hates A records on domain names ;-))
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: Blocks URIs
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Mardi, 23 sep 2003, à 14:38 Europe/Zurich, Stefano Mazzocchi a écrit
:
> ...Sylvain pointed out the case where a namespace needs to be
> associated to a particular block, but the more I think about this, the
> more I think this is wrong and shouldn't happen.
>
> I have no problems if one 'certified' cocoon block uses a particular
> namespace that had to create because nobody else provides it, but this
> namespace should *NOT* be associated with that block anyhow...
>
Sounds reasonable - either namespaces are of general use and
"registered" as such, or they are not associated with a particular
block.
> I would go as far as saying that is should *NOT* be allowed to have a
> namespace associated to a particular block or that contains the word
> "block" inside, unless is a namespace that about *blocks in general*
> (say the namespace of the block wiring markup, for example).
Yes, will help avoid confusion.
> With this restriction, we can use one single scheme and have
>
> http://apache.org/cocoon/ -> Cocoon URI prefix
>
> http://apache.org/cocoon/block/ -> Cocoon Block-ID URI prefix
>
> where "namespaces" have to belong to the cocoon URI prefix but *NOT*
> on the Cocoon Block-ID URI prefix.
Sounds good to me!
-Bertrand
Re: Blocks URIs
Posted by Stefano Mazzocchi <st...@apache.org>.
On Tuesday, Sep 23, 2003, at 14:10 Europe/Rome, Bertrand Delacretaz
wrote:
> Le Mardi, 23 sep 2003, à 14:03 Europe/Zurich, Stefano Mazzocchi a
> écrit :
>> ...Yeah, well, too bad we already have something along 20 namespaces
>> who already don't follow that convention.
>
> We could for blocks at least, couldn't we?
>
> using
>
> http://apache.org/cocoon/block/pdf/namespaces/foo/.1.0
>
> instead of
>
> http://apache.org/cocoon/blocks/pdf/foo/.1.0
yes, but there are a few things I dislike about that:
1) the URI space of blocks id and namespaces get mixed
2) the above seems to suggest that block implementors are freed from
the usual namespace-creation policies under cocoon.
Sylvain pointed out the case where a namespace needs to be associated
to a particular block, but the more I think about this, the more I
think this is wrong and shouldn't happen.
I have no problems if one 'certified' cocoon block uses a particular
namespace that had to create because nobody else provides it, but this
namespace should *NOT* be associated with that block anyhow.
I would go as far as saying that is should *NOT* be allowed to have a
namespace associated to a particular block or that contains the word
"block" inside, unless is a namespace that about *blocks in general*
(say the namespace of the block wiring markup, for example)
With this restriction, we can use one single scheme and have
http://apache.org/cocoon/ -> Cocoon URI prefix
http://apache.org/cocoon/block/ -> Cocoon Block-ID URI prefix
where "namespaces" have to belong to the cocoon URI prefix but *NOT* on
the Cocoon Block-ID URI prefix.
This would remove the need of a duplicate URI prefix
http://cocoon.apache.org/cocoon.
Thoughts?
--
Stefano.
Re: Blocks URIs
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Mardi, 23 sep 2003, à 14:03 Europe/Zurich, Stefano Mazzocchi a écrit
:
> ...Yeah, well, too bad we already have something along 20 namespaces
> who already don't follow that convention.
We could for blocks at least, couldn't we?
using
http://apache.org/cocoon/block/pdf/namespaces/foo/.1.0
instead of
http://apache.org/cocoon/blocks/pdf/foo/.1.0
-Bertrand
Re: Blocks URIs
Posted by Stefano Mazzocchi <st...@apache.org>.
On Tuesday, Sep 23, 2003, at 07:38 Europe/Rome, Bertrand Delacretaz
wrote:
>
> Le Lundi, 22 sep 2003, à 15:59 Europe/Zurich, Stefano Mazzocchi a
> écrit :
>> On Monday, Sep 22, 2003, at 14:05 Europe/Rome, Sylvain Wallez wrote:
>>> ...
>>> Taking the above example, does this mean :
>>> - http://cocoon.apache.org/blocks/pdf/1.0 for the block ID and
>>> - http://apache.org/cocoon/blocks/pdf/foo/.1.0 for the "foo"
>>> namespace defined by the pdf block ?
>>>
>>> Mmmh... it certainly avoids conflicts, but can be confusing and
>>> looks somewhat inconsistent : why apache.org/cocoon on one side and
>>> cocoon.apache.org on the other side ?
>>
>> because all namespaces (and only those!) are located on
>> apache.org/cocoon. I think this is very consistent.
>
> Sorry to jump in late, but at some point I saw the word "namespaces"
> in these URIs, and I think it can help avoid confusion.
>
> Why not
>
> http://namespaces.apache.org/cocoon...
>
> for namespaces?
>
>
> But it might be too late to change this one, so maybe use
>
> http://apache.org/cocoon/block/pdf/namespaces/foo/.1.0
>
> instead of
>
> http://apache.org/cocoon/blocks/pdf/foo/.1.0
>
> for the "foo" namespace defined by the pdf block ?
>
> The idea is to make these URI's purpose explicit without hidden
> conventions.
Yeah, well, too bad we already have something along 20 namespaces who
already don't follow that convention.
--
Stefano.
Re: Blocks URIs
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Lundi, 22 sep 2003, à 15:59 Europe/Zurich, Stefano Mazzocchi a écrit
:
> On Monday, Sep 22, 2003, at 14:05 Europe/Rome, Sylvain Wallez wrote:
>> ...
>> Taking the above example, does this mean :
>> - http://cocoon.apache.org/blocks/pdf/1.0 for the block ID and
>> - http://apache.org/cocoon/blocks/pdf/foo/.1.0 for the "foo"
>> namespace defined by the pdf block ?
>>
>> Mmmh... it certainly avoids conflicts, but can be confusing and looks
>> somewhat inconsistent : why apache.org/cocoon on one side and
>> cocoon.apache.org on the other side ?
>
> because all namespaces (and only those!) are located on
> apache.org/cocoon. I think this is very consistent.
Sorry to jump in late, but at some point I saw the word "namespaces" in
these URIs, and I think it can help avoid confusion.
Why not
http://namespaces.apache.org/cocoon...
for namespaces?
But it might be too late to change this one, so maybe use
http://apache.org/cocoon/block/pdf/namespaces/foo/.1.0
instead of
http://apache.org/cocoon/blocks/pdf/foo/.1.0
for the "foo" namespace defined by the pdf block ?
The idea is to make these URI's purpose explicit without hidden
conventions.
-Bertrand
Re: Blocks URIs
Posted by Stefano Mazzocchi <st...@apache.org>.
On Monday, Sep 22, 2003, at 14:05 Europe/Rome, Sylvain Wallez wrote:
> Stefano Mazzocchi wrote:
>
>>
>> On Monday, Sep 22, 2003, at 00:38 Europe/Rome, Ugo Cei wrote:
>>
>>> Stefano Mazzocchi wrote:
>>>
>>>> On Sunday, Sep 21, 2003, at 18:46 Europe/Rome, Sylvain Wallez wrote:
>>>>
>>>>> 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 ?
>>>>
>>>> I'm not enthusiastic about it, but I can't come up with anything
>>>> better than this.
>>>> Does anybody else care about this? alternative ideas anyone?
>>>
>>>
>>> Since the block id should be a resolvable URL, why not
>>> http://cocoon.apache.org/blocks/pdf/1.0 ?
>>>
>>> This way, it's difficult to confuse it with the namespace and we
>>> don't need any rewrites on apache.org.
>>
>>
>> D'oh! you are so right. +1
>>
>> what do others think?
>
>
> Taking the above example, does this mean :
> - http://cocoon.apache.org/blocks/pdf/1.0 for the block ID and
> - http://apache.org/cocoon/blocks/pdf/foo/.1.0 for the "foo" namespace
> defined by the pdf block ?
>
> Mmmh... it certainly avoids conflicts, but can be confusing and looks
> somewhat inconsistent : why apache.org/cocoon on one side and
> cocoon.apache.org on the other side ?
because all namespaces (and only those!) are located on
apache.org/cocoon. I think this is very consistent.
Besides, it is rare that you use block-id *and* namespaces in the same
document... and users never have to do that, only block developers in
the block.xml file.
> Remember : you moved namespaces from xml.apache.org/cocoon to
> apache.org/cocoon because of the promotion of Cocoon to top-level
> project. What if we decide in the future to rename the TLP from
> "cocoon" to e.g. "cms" ??
and what if we change the name of the project to "blaboon" because Sony
decided to sue us for trademark infringment? [ for the movie or for the
tivo-like thing]
or what if the apache nation changes leaders and they want royalties
from their name and we are required to change the ASF main location?
good URI shouldn't change, but it's hard to avoid changing something
that has a meaning associated to it... because that meaning drifts with
time. This is why DOI, for example, uses numbers instead.
for example, TimBL explained that the use of 1999 in the XSLT namespace
is because in a hundreds years from now, people might want to reuse the
XSLT name to mean something completely different.
Forward thinking or egocentric naiveness?
cocoon.apache.org is not going anywhere from all the signals I can
feel, so it seems solid enough to base this infrastucture upon.
--
Stefano.
Re: Blocks URIs
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Stefano Mazzocchi wrote:
>
> On Monday, Sep 22, 2003, at 00:38 Europe/Rome, Ugo Cei wrote:
>
>> Stefano Mazzocchi wrote:
>>
>>> On Sunday, Sep 21, 2003, at 18:46 Europe/Rome, Sylvain Wallez wrote:
>>>
>>>> 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 ?
>>>
>>> I'm not enthusiastic about it, but I can't come up with anything
>>> better than this.
>>> Does anybody else care about this? alternative ideas anyone?
>>
>>
>> Since the block id should be a resolvable URL, why not
>> http://cocoon.apache.org/blocks/pdf/1.0 ?
>>
>> This way, it's difficult to confuse it with the namespace and we
>> don't need any rewrites on apache.org.
>
>
> D'oh! you are so right. +1
>
> what do others think?
Taking the above example, does this mean :
- http://cocoon.apache.org/blocks/pdf/1.0 for the block ID and
- http://apache.org/cocoon/blocks/pdf/foo/.1.0 for the "foo" namespace
defined by the pdf block ?
Mmmh... it certainly avoids conflicts, but can be confusing and looks
somewhat inconsistent : why apache.org/cocoon on one side and
cocoon.apache.org on the other side ?
Remember : you moved namespaces from xml.apache.org/cocoon to
apache.org/cocoon because of the promotion of Cocoon to top-level
project. What if we decide in the future to rename the TLP from "cocoon"
to e.g. "cms" ??
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
Re: Blocks URIs
Posted by Stefano Mazzocchi <st...@apache.org>.
On Monday, Sep 22, 2003, at 00:38 Europe/Rome, Ugo Cei wrote:
> Stefano Mazzocchi wrote:
>> On Sunday, Sep 21, 2003, at 18:46 Europe/Rome, Sylvain Wallez wrote:
>>> 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 ?
>> I'm not enthusiastic about it, but I can't come up with anything
>> better than this.
>> Does anybody else care about this? alternative ideas anyone?
>
> Since the block id should be a resolvable URL, why not
> http://cocoon.apache.org/blocks/pdf/1.0 ?
>
> This way, it's difficult to confuse it with the namespace and we don't
> need any rewrites on apache.org.
D'oh! you are so right. +1
what do others think?
--
Stefano.
Re: Blocks URIs
Posted by Ugo Cei <u....@cbim.it>.
Stefano Mazzocchi wrote:
> On Sunday, Sep 21, 2003, at 18:46 Europe/Rome, Sylvain Wallez wrote:
>> 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 ?
> I'm not enthusiastic about it, but I can't come up with anything better
> than this.
>
> Does anybody else care about this? alternative ideas anyone?
Since the block id should be a resolvable URL, why not
http://cocoon.apache.org/blocks/pdf/1.0 ?
This way, it's difficult to confuse it with the namespace and we don't
need any rewrites on apache.org.
Ugo
Re: Blocks URIs
Posted by Stefano Mazzocchi <st...@apache.org>.
On Sunday, Sep 21, 2003, at 18:46 Europe/Rome, Sylvain Wallez wrote:
> 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.
I'm not enthusiastic about it, but I can't come up with anything better
than this.
Does anybody else care about this? alternative ideas anyone?
--
Stefano.
Re: Blocks URIs
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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
Re: Blocks URIs
Posted by Stefano Mazzocchi <st...@apache.org>.
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
;-)
[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.
Re: Blocks URIs
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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. 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