cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Hunsberger <>
Subject Re: [RT] Escaping Sitemap Hell
Date Thu, 06 Jan 2005 15:42:08 GMT
On Thu, 06 Jan 2005 01:54:09 +0100, Daniel Fagerstrom
<> wrote:
>  (was: Splitting xconf files step 2: the sitemap)

Interesting thoughts, I didn't get much sleep last night, so excuse me
if any of the following comes across as a bit grumpy, no flames or
criticism is intended...

(Excuse the random un-annotated snips, don't have much time today.)

> Although the Cocoon sitemap is a really cool innovation it is not
> entierly without problems:
> * Sitemaps for large webapps easy becomes a mess
> * It sucks as a map describing the site [1]
> * It doesn't give that much support for "cool URLs" [2]

Except for the issue of matching which you get into later, I'm not
sure that I see a big problem here:

- sitemaps for large webapps only become a mess if you design the URL
space badly.  Better suport for matching could help, and that issue
might be tied to how the sitemap is managed within Cocoon, but my gut
feel says it's just a matcher issue;

- a Cocoon sitemap is not Website site map, nor should it be.  Maybe
the name "sitemap" isn't the best? I think having the ability to
produce a "URL Map" from something that crawls the sitemap is maybe
part of the answer here.

- I don't think support of Cool URLs is supported or hindered by the
sitemap ? Maybe more on that below.


> The Resource
> ------------
> The idea is that an URL identifies a resource. For the patient case
> above it could be:
> If we use a hierarchial URI space like /person/123456789, the "parent"
> URIs e.g. /person should also refer to a resource. Its in most cases not
> a good idea to put a lot of topics classification effort in the URI
> hierarchy. Classifications are not unique and will change according to
> changing interests and world view.

I tend to map my URL hierarchy to an abstract object hierarchy.  In
this case patient can be thought of as an object.  The patient with
the id 12345678 is an instance and as such that identifier should not
be part of the URL hierarchy.  Instead, object attributes become
request parameters. This may seem like a quibble but I think it's
important as one tries to figure out good rules for hierarchy mapping.

> Operations
> ----------
> What about the operations on the resource: list, search, edit etc? I
> find the object oriented style in WebDAV elegant where you use one URL
> together with different HTTP methods to perform different operations.
> Sam Ruby also have some intersting ideas about using URLs to identify
> "objects" and different SOAP messages for different methods on the
> object in his "REST+SOAP" article [4]. But neither adhoc HTTP methods or
> XML posts seem like good candidates for invoking operations on a
> resource in a typical webapp. So maybe something like:
> /person/123456789/edit or
> /person/123456789.edit or
> /person/123456789?operation=edit

Ok, next rule: operations map to methods, not to hierarchy or to
attributes.  As such, that's why I introduce the "." notation; to
separate the concerns.  Thus, so far the general rule is:


Your mileage may vary, but it works for us...

> Resource Type
> -------------
> Should the type of the resource be part of the URI? We probably have to
> contain some type info in the URL to give it "independent sematics"
> (person e.g.). But we should not put types that might change like
> patient, manager, project-leader etc in the URL. And we should
> especially avoid types that only have to do with implementation details
> like what pipeline we want to use for rendering the resource.

Keep the objects abstract :-)...

> Format
> ------
> Cocoon especially shines in handling all the various file name
> extensions: .html, .wml, .pdf, .txt, .doc, .jpg, .png, .svg, etc, etc.
> But I'm sorry, if you want cool URLs you have to kiss them godbye as well ;)

> But in most cases file name extensions is an implementation detail that
> not is relevant for your users.

Makes sense, in our case much of the time operations and format are
interchangeable and there may be defaults.  Thus:


might be the same as:


Don't know if it helps, but you can think of format as an object
method to get a specific output format...


> Does Cocoon Support Cool URLs?
> ==============================
> But how does Cocoon support the above ideas about URL space design?
> Well, in some way one could say that it supports it. The sitemap is so
> powerfull that you can program most usage patterns in it in some more or
> less elegant way. But AFAICS, writing webapps following the URL space
> design ideas above would be rather tricky. So I would say that Cocoon
> doesn't support it that well. The main reasons are:
> * The sitemap is not that usefull as a site map
> * The sitemap gives excelent support for choosing resource production
> implementation based on the implementation details coded into the URL,
> but not for avoiding it
> * The sitemap mixes site map concerns with resource production
> implementation details

I think this all goes back to my initial comments: need a "URL Map"
producer and better matching?


> Before I suggested that aspects like: type, format, status, access
> rights etc shouldn't be part of the URL as those aspects might change
> for the resource. OTH these aspects certainly are necessary for choosing
> rendering pipeline, what should we do?

This is where the difference between resource publishing and browser
based application support start to matter.  It seems to me that maybe
you are coming at this more from an application support perspective
than a resource publishing perspective? If so, I'll note that you want
to separate the issue of layout from the choice of pipeline.  In
particular, in an application it's better to have the URL behave in a
friendly way than to stay "cool" at all times.  For example:


might produce a search layout if no match was found, a list layout if
multiple matches was found or an edit layout if a single match was
found.  All of these might be considered different renderings of a
single "resource".  On might (perhaps rightfully) think that I'm
stretching TBL's definition of resource, but consider that if there
was no application behind the scenes (and thus the data never changed)
then this URL would turn "cool" since it would always produce the same


> The new sitemap
> ===========
> To sum up the proposal:
> Pipelines:
> * Pipeline construction is only done as VPCs in component areas (often
> in blocks).

As has been pointed out, flow also gives you a way to separate these concerns...

> Sitemap:
> * The sitemap is folow the tree structure of the URL space (like the
> Forrest linkmap).
> * Its responsibillity is to map URLs to VPCs
> * It can set the current context for each level in the tree (for
> derefering relative paths used in the VPC)
> * Wildcards can have restrictions based on properties in the content
> repository
> * Its best match based rather than rule order based
> * Of course we have an include construct so that we can reuse sub sites
> It might look like:
> <sitemap>
>  <path match="person" context="adm/persons"
> pipeline="block:skin:default(search.xml)">
>    <path match="*:patient" test="mydb:/patients/{patient} exists"
> context="adm/patients" pipeline="journal-summary({patient})">
>      <path match="edit" pipeline="edit({patient})"/>
>      <path match="list" pipeline="list({patient})"/>
>      <!-- and so on -->
>    </path>
>  </path>
> </sitemap>

I think you're reinventing flow in XML that isn't even XSLT.  I'd
prefer an XSLT based sitemap :-)


> Much of what I propose can be achieved with VPCs and a new "property
> aware" matcher. But IMO the stricter SoC above, the ability to "query"
> the sitemap, the possible advantages of the "best match" search, are
> reasons enough to go further.

Better matching would help, but again flow can already do most of what
you describe.  The ability to query the sitemap to get a link map/url
map might be the most important thing.

I'll likely be offline for the next couple of days, small odd's of
being able to contribute further to this thread.  Good luck :-)

Peter Hunsberger

View raw message