cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Date-specific resources
Date Sat, 01 Dec 2001 14:33:44 GMT
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.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message