Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Message-ID: <395F3C0B.A3B7CDE4@apache.org>
Date: Sun, 02 Jul 2000 14:56:43 +0200
From: Stefano Mazzocchi <stefano@apache.org>
Organization: Apache Software Foundation
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [RT] resource views, error handling, pipeline debugging
References: <395A0DA1.46AD91B4@apache.org>
	 <395AE5BF.CC2DD737@localbar.com> <395B2C04.58470D2B@apache.org>
	 <395C1CE6.5065470E@localbar.com> <395C9296.519C4FF3@apache.org>
 <p04320404b58360589bdc@[192.168.0.2]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jeremy Quinn wrote:

> >3 choices;
> >a)  Extension to the path.
> >b) cocoon-view parameter
> >c) any parameter indicated by a configuration property.
> >
> >I vote for b.
> 
> I've always preferred option (a).
> I find query parameters aesthetically displeasing, particularly on public URLs.
> Keep query params for when there is really no other option IMHO.

I generally share your vision on this, but here is different.

We must introduce the notion of cocoon views, while the general idea of
"views" is not enforced by Cocoon but it's up to you (like for your
"noise"), cocoon-view are special views that are enforced by the sitemap
semantics.

For example, soppose you have

 http://host/images/logo

then you do

 http://host/images/logo/blackandwhite
 http://host/images/logo/a-la-van-gogh
 http://host/images/logo/for-print
 http://host/images/logo/for-web
 http://host/images/logo/for-wap

and so on. These are "functional views" of the same resource, but may
not apply to any other resource inside your URI space. So you must using
normal matching in the sitemap to achieve this (thru different XSLT or
reading different files... up to you).

Very different is the situation where you want, for example, to crawl a
site using XLink information. You _MUST_ know how to access that
hyperlink view, it must be a standard way of doing this.

So, you could try
 
 http://host/path/resource/hyperlink

but then you might end up with name conflicts (having one of your
inherited sitemaps that matches this very URI and overloads this view
capabilities). Something like this would totally break the crawling
experience and leave parts of the site unexplorable.

We could try to use sort-of namespaces for URI fragments so

 http://host/path/resource/cocoon-view-hyperlink

but this is nothing better than

 http://host/path/resource?cocoon-view="hyperlink"

or less verbose (assuming view names are single words)

 http://host/path/resource?cocoon-view=hyperlink
 
Even if the syntax is very similar

 http://host/path/resource/cocoon-view-hyperlink
 http://host/path/resource?cocoon-view=hyperlink

the two notions are completely different. Parameters seem to me more
"orthogonal" to the URI space, but admittedly this is a very subjective
idea.

Any comment or suggestion on how to encode view inside HTTP URIs?

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------