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:[EMAIL PROTECTED]] > Sent: Saturday, 01 December 2001 2:34 pm > To: [EMAIL PROTECTED] > 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. > <[EMAIL PROTECTED]> Friedrich Nietzsche > -------------------------------------------------------------------- > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
