cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Morrison" <john.r.morri...@ntlworld.com>
Subject RE: Date-specific resources
Date Sat, 01 Dec 2001 14:42:03 GMT
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.
> <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
>


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


Mime
View raw message