You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Jeff Turner <je...@socialchange.net.au> on 2001/12/01 01:19:08 UTC
Date-specific resources (Re: Cleaning up dist directory)
On Fri, Nov 30, 2001 at 05:02:35PM +0100, Stefano Mazzocchi wrote:
> Jeff Turner wrote:
[..]
> > I
> > understand the reason for this; the only problem is that when Cocoon 3
> > arrives, everyone's URLs will break again. A nicer solution would be to
> > have:
> >
> > http://xml.apache.org/cocoon1
> > http://xml.apache.org/cocoon2
> > http://xml.apache.org/cocoon3
> >
> > and then use mod_rewrite to make http://xml.apache.org/cocoon/ reflect
> > whatever is the current version.
>
> Forget it! The Cocoon homepage *is* http://xml.apache.org/cocoon/.
>
> Period.
>
> We will never have other URIs, we'll keep all the documentation inside
> and work more evolutionarely from now on (no big transitions).
What use is a stable URI if the resource it references keeps changing?
Say I write a HTML page, "How to install Cocoon 2 with FooBar
extensions". I want to reference the content currently at:
http://xml.apache.org/cocoon/installing/
But I can't, because when Cocoon 2.x or 3 comes out, it won't be the
same content I intended to reference.
It's a Cool URI, but it ain't a Cool Resource, because it keeps changing
:)
My mod_rewrite suggestion above is one solution; have two URIs per
resource, one stable, one changing.
This is far from a Cocoon-specific problem though. It would be nice if
there were a HTTP header, by which one could specify "Give me the
version of resource X at date Y". This could even be
implemented with Cocoon, if there were a magic "date" param, and if
there were a "cvs://" protocol to provide a backend. Hmm...
--Jeff
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Date-specific resources
Posted by Jeff Turner <je...@socialchange.net.au>.
On Sat, Dec 01, 2001 at 03:33:44PM +0100, Stefano Mazzocchi wrote:
[..]
> Back to the Cocoon URI-space problem. The URI
>
> http://xml.apache.org/cocoon/installing
>
> "identifies" information about "installing Apache Cocoon" and "locates"
> the latest version of this document.
>
> If we found valuable (but I do not, having CVS) to create contracts to
> both "identify" and "locate" a specific time-based or version-based
> information inside the Cocoon namespace, we would provide you with that
> contract, but it is *NOT* our fault if you are using one 'identifier' as
> a contract for something else!
Don't be so defensive! I said "I can't rely on this because it will
change". You've replied, "No you can't, and it's your own fault if you
do". Fine; perhaps the text below will convince you that this is a real
problem.
> So, your mod_rewrite solution (or any other solution that maps a
> specific time/version information to the site) would be neede *IF* we
> choosen to provide that information on the web. But again, given the
> ability to obtain that information from CVS, I don't (personally) find
> it of any use since 99% of the people wants the latest information.
Do you *really* think that 99% of users are using the latest Cocoon?
Browse through the cocoon-users archive; there are *plenty* of Cocoon
1.8 installs still out there. I have about 5 of them myself. We have no
plans to move to Cocoon 2.0, because 1.8 works perfectly.
Now one could say "tough luck, losing the docs is one of the costs of
not staying current", but that would demonstrate a disquieting lack of
respect for those with investments in older versions. What is current
today is "old" tomorrow. How can I base my million-dollar system on
Cocoon 2.0, if when Cocoon 2.1 comes along, all trace of Cocoon 2.0
effectively vanishes for those without CVS access? Is there some rule
stating that websites should only be useful for those on the cutting
edge?
Once again, this is a very general problem. Unless someone has a
brilliant suggestion, or everyone is prepared to adopt a versioned-URL +
mod_rewrite solution, we should let it drop.
--Jeff
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Date-specific resources
Posted by Stefano Mazzocchi <st...@apache.org>.
I'm replying to all other posts on this thread since I wasn't probably
clear enough on my goals.
Hope this clarifies the issue.
John Morrison wrote:
>
> Maybe that's the ideal when the information being represented is version
> agnostic - but this isn't. What do you recommend?
I perfectly see the reason to support Cocoon1 users and I consider this
vital for the reputation of this project (I never stated the opposite).
My point is that we need to support only the *head* of the documentation
for each incompatible generation of our software, not every single
version.
Since we have two (and only two) incompatible generations and we won't
have more than those, I'd like to see this included into the URI
semantics:
current generation [Today Cocoon 2.0]
identified by "http://xml.apache.org/cocoon/"
deprecated (but still actively used) generation [Today Cocoon 1.8.2]
identified by "http://xml.apache.org/cocoon/deprecated/"
[DISCLAIMER: I don't like the term 'deprecated' myself but I couldn't
comeup with a better expression for that. If you do, please, make
yourself heard]
But URI should be version-number-agnostic or we'll need to do break
things again later on.
I do see the need for making available the old-generation documentation,
it's a big need and I'm fully supportive, but I don't see the need to
make available the documentation for each and every version given than:
1) each Cocoon version is still downloadable (nothing will *ever* be
deleted from the /dist directory!) and it contains its own documentation
2) the CVS contains all possible versions and differences even between
the releases (granularity is complete).
So, my vision is:
1) people coming to the site want both the latest and the most used
(they might be coincident at one point in the future, but it's generally
a mistake to believe the latest is always the most used)
2) people that require a specific version can always download that.
3) people that want something more specific, can use the CVSWeb
interface or the CVS itself.
Sorry if my previous comment wasn't clear.
I hope this clarifies the issues.
If not or if you disagree, please comment on.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Date-specific resources
Posted by John Morrison <jo...@ntlworld.com>.
Maybe that's the ideal when the information being represented is version
agnostic - but this isn't. What do you recommend?
> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> Sent: Saturday, 01 December 2001 8:46 pm
> To: cocoon-dev@xml.apache.org
> Subject: Re: Date-specific resources
>
>
> John Morrison wrote:
> >
> > So we should have...
> >
> > http://xml.apache.org/cocoon/1/
> > http://xml.apache.org/cocoon/2/
> >
> > and
> >
> > http://xml.apache.org/cocoon/ -> http://xml.apache.cocoon/2/
> >
> > Yes?
>
> No. Cocoon URIs must be version agnostic, they must convey only semantic
> meaning.
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Date-specific resources
Posted by Stefano Mazzocchi <st...@apache.org>.
John Morrison wrote:
>
> So we should have...
>
> http://xml.apache.org/cocoon/1/
> http://xml.apache.org/cocoon/2/
>
> and
>
> http://xml.apache.org/cocoon/ -> http://xml.apache.cocoon/2/
>
> Yes?
No. Cocoon URIs must be version agnostic, they must convey only semantic
meaning.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Date-specific resources
Posted by John Morrison <jo...@ntlworld.com>.
So we should have...
http://xml.apache.org/cocoon/1/
http://xml.apache.org/cocoon/2/
and
http://xml.apache.org/cocoon/ -> http://xml.apache.cocoon/2/
Yes?
> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> Sent: Saturday, 01 December 2001 2:34 pm
> To: cocoon-dev@xml.apache.org
> Subject: Re: Date-specific resources
>
>
> Jeff Turner wrote:
>
> > Say I write a HTML page, "How to install Cocoon 2 with FooBar
> > extensions". I want to reference the content currently at:
> >
> > http://xml.apache.org/cocoon/installing/
> >
> > But I can't, because when Cocoon 2.x or 3 comes out, it won't be the
> > same content I intended to reference.
> >
> > It's a Cool URI, but it ain't a Cool Resource, because it keeps changing
> > :)
> >
> > My mod_rewrite suggestion above is one solution; have two URIs per
> > resource, one stable, one changing.
> >
> > This is far from a Cocoon-specific problem though. It would be nice if
> > there were a HTTP header, by which one could specify "Give me the
> > version of resource X at date Y". This could even be
> > implemented with Cocoon, if there were a magic "date" param, and if
> > there were a "cvs://" protocol to provide a backend. Hmm...
>
> The W3C is using dates as a way to identify 'long-living' URIs.
>
> Let me tell you that I *HATE* this approach!
>
> For example: the XSLT namespace is
>
> http://www.w3.org/1999/XSL/Transform
>
> There is a *BIG* problem in this: 1999 is the year the specification got
> recommended, it's *NOT* the version of the product. In fact, the
> namespace for, say, M$ Windows 2000 could well be
>
> http://microsoft.com/windows/2000/
>
> but this is not the same thing since it doesn't force me to "map" my
> mental identifier for the technology (the version) with their timeline
> locator (the year it was released).
>
> If I was the W3C, I would have written something like
>
> http://w3.org/XSLT/1.0
>
> which is:
>
> 1) more solid and general since it doesn't specify "www"
> 2) easier to remember and to 'guess': if I the URI scheme is coherent,
> I can create it by hand without knowing it in advance (like I do for web
> sites: http:// + www. + company-name + .com)
> 3) more expressive: you can't have more than one spec release per year.
>
> Ok, this is only to show you that even the web gurus at W3C don't know
> how to create URIs.
>
> Back to the Cocoon URI-space problem. The URI
>
> http://xml.apache.org/cocoon/installing
>
> "identifies" information about "installing Apache Cocoon" and "locates"
> the latest version of this document.
>
> If we found valuable (but I do not, having CVS) to create contracts to
> both "identify" and "locate" a specific time-based or version-based
> information inside the Cocoon namespace, we would provide you with that
> contract, but it is *NOT* our fault if you are using one 'identifier' as
> a contract for something else!
>
> So, your mod_rewrite solution (or any other solution that maps a
> specific time/version information to the site) would be neede *IF* we
> choosen to provide that information on the web. But again, given the
> ability to obtain that information from CVS, I don't (personally) find
> it of any use since 99% of the people wants the latest information.
>
> Since this wasn't clear before (admittedly, the URI/URL difference is
> very thin and requires lots of semantic reasoning), let me state it
> clearly:
>
> The URI "http://xml.apache.org/cocoon/" identifies the homepage for the
> Apache Cocoon project and "locates" its latest version.
>
> Each URI which is relative from the above identifies a page that gives
> some specific information (for example, on 'installing Apache Cocoon')
> and locates the latest version.
>
> If you use this contract to indicate something else (for example, how to
> install Cocoon 2.0RC2), it's *NOT* our fault if your link is
> semantically broken: we never guaranteed you that that URI identified a
> version-specific inforamtion (nor we want to!)
>
> If you connected to http:xml.apache.org/cocoon/installing and it started
> talking about "apple and oranged", in that case, yes, you'd be right: we
> broke the contract.
>
> The http://xml.apache.org/cocoon2/ URI is utterly wrong because it
> identifies and locates a specific version range, thus overlapping
> concerns. This is why I didn't want to make the release without this
> fixed.
>
> The http://xml.apache.org/cocoon1/ is even worse, it should be something
> like:
>
> http://xml.apache.org/cocoon/deprecated/
>
> or
>
> http://xml.apache.org/cocoon/old/
>
> or
>
> http://xml.apache.org/cocoon/previous-generation/
>
> which is version independent and gives you a link to "deprecated
> documentation of the past of Apache Cocoon that legacy users might still
> require".
>
> We have to fix the stupid /cocoon1/ hack soon, before people start using
> it as a contract.
>
> Hope this solves your issues.
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Date-specific resources
Posted by Michael Hartle <mh...@hartle-klug.com>.
Stefano Mazzocchi wrote:
>Back to the Cocoon URI-space problem. The URI
>
> http://xml.apache.org/cocoon/installing
>
>"identifies" information about "installing Apache Cocoon" and "locates"
>the latest version of this document.
>
>If we found valuable (but I do not, having CVS) to create contracts to
>both "identify" and "locate" a specific time-based or version-based
>information inside the Cocoon namespace, we would provide you with that
>contract, but it is *NOT* our fault if you are using one 'identifier' as
>a contract for something else!
>
Admitted, when being a CVS pro and knowing that the Cocoon website is
available on the CVS, too, then anyone is free to travel back to any
version of Cocoon. I doubt the majority of the regular
only-readers/participators-not-committers of cocoon-dev are able to do
so instantly, without stumbling about a lack of CVS knowledge here or
there. Be honest to yourself, we are all humans.
On Cocoon 1.8.2, obviously individuals and companies have invested time
and money into projects based on a now "deprecated" version, but this
does not mean they all can transfer their investment and knowledge
instantly to the new Cocoon 2.0 release, even when they would be happily
willing to do so; those need a unobstructed, consistent and *documented*
manner of getting to information relating to their version. The feeling
of being left behing every major release or so is pretty scary to any
long-term project investment. Showing persistance in a project builds
confidence and showing where Cocoon has been (version- and
technology-like) and how it has evolved in quality can only add to the
reputation.
The means of how to satisfy the demand for such access is disputable - I
respect your opinion regarding version-based URIs - but the request is
still a legitimate one and at least deserves respect and attention. So
let's return to a constructive approach; Stefano, do you see a solution
you would consider acceptable ? Would the idea of pre-packaged zip
version-related CVS-snapshots of the documentation/website/source
available as "deprecated" download be a way ?
Best regards,
Michael Hartle
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Date-specific resources
Posted by Stefano Mazzocchi <st...@apache.org>.
Jeff Turner wrote:
> Say I write a HTML page, "How to install Cocoon 2 with FooBar
> extensions". I want to reference the content currently at:
>
> http://xml.apache.org/cocoon/installing/
>
> But I can't, because when Cocoon 2.x or 3 comes out, it won't be the
> same content I intended to reference.
>
> It's a Cool URI, but it ain't a Cool Resource, because it keeps changing
> :)
>
> My mod_rewrite suggestion above is one solution; have two URIs per
> resource, one stable, one changing.
>
> This is far from a Cocoon-specific problem though. It would be nice if
> there were a HTTP header, by which one could specify "Give me the
> version of resource X at date Y". This could even be
> implemented with Cocoon, if there were a magic "date" param, and if
> there were a "cvs://" protocol to provide a backend. Hmm...
The W3C is using dates as a way to identify 'long-living' URIs.
Let me tell you that I *HATE* this approach!
For example: the XSLT namespace is
http://www.w3.org/1999/XSL/Transform
There is a *BIG* problem in this: 1999 is the year the specification got
recommended, it's *NOT* the version of the product. In fact, the
namespace for, say, M$ Windows 2000 could well be
http://microsoft.com/windows/2000/
but this is not the same thing since it doesn't force me to "map" my
mental identifier for the technology (the version) with their timeline
locator (the year it was released).
If I was the W3C, I would have written something like
http://w3.org/XSLT/1.0
which is:
1) more solid and general since it doesn't specify "www"
2) easier to remember and to 'guess': if I the URI scheme is coherent,
I can create it by hand without knowing it in advance (like I do for web
sites: http:// + www. + company-name + .com)
3) more expressive: you can't have more than one spec release per year.
Ok, this is only to show you that even the web gurus at W3C don't know
how to create URIs.
Back to the Cocoon URI-space problem. The URI
http://xml.apache.org/cocoon/installing
"identifies" information about "installing Apache Cocoon" and "locates"
the latest version of this document.
If we found valuable (but I do not, having CVS) to create contracts to
both "identify" and "locate" a specific time-based or version-based
information inside the Cocoon namespace, we would provide you with that
contract, but it is *NOT* our fault if you are using one 'identifier' as
a contract for something else!
So, your mod_rewrite solution (or any other solution that maps a
specific time/version information to the site) would be neede *IF* we
choosen to provide that information on the web. But again, given the
ability to obtain that information from CVS, I don't (personally) find
it of any use since 99% of the people wants the latest information.
Since this wasn't clear before (admittedly, the URI/URL difference is
very thin and requires lots of semantic reasoning), let me state it
clearly:
The URI "http://xml.apache.org/cocoon/" identifies the homepage for the
Apache Cocoon project and "locates" its latest version.
Each URI which is relative from the above identifies a page that gives
some specific information (for example, on 'installing Apache Cocoon')
and locates the latest version.
If you use this contract to indicate something else (for example, how to
install Cocoon 2.0RC2), it's *NOT* our fault if your link is
semantically broken: we never guaranteed you that that URI identified a
version-specific inforamtion (nor we want to!)
If you connected to http:xml.apache.org/cocoon/installing and it started
talking about "apple and oranged", in that case, yes, you'd be right: we
broke the contract.
The http://xml.apache.org/cocoon2/ URI is utterly wrong because it
identifies and locates a specific version range, thus overlapping
concerns. This is why I didn't want to make the release without this
fixed.
The http://xml.apache.org/cocoon1/ is even worse, it should be something
like:
http://xml.apache.org/cocoon/deprecated/
or
http://xml.apache.org/cocoon/old/
or
http://xml.apache.org/cocoon/previous-generation/
which is version independent and gives you a link to "deprecated
documentation of the past of Apache Cocoon that legacy users might still
require".
We have to fix the stupid /cocoon1/ hack soon, before people start using
it as a contract.
Hope this solves your issues.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org