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]
