Re: Blocks URIs
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
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
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
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
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
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
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
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
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
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
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
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
[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.
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
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.
Re: Blocks URIs
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. 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
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 [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? -- Stefano.
