cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Ezkovich <>
Subject Re: [RT] Escaping Sitemap Hell
Date Sun, 09 Jan 2005 00:48:29 GMT

On Jan 7, 2005, at 10:30 PM, Peter Hunsberger wrote:

> On Fri, 7 Jan 2005 17:38:35 -0600, Glen Ezkovich <> 
> wrote:
>> On Jan 7, 2005, at 1:43 PM, Peter Hunsberger wrote:
>>> On Fri, 07 Jan 2005 14:28:06 -0500, Stefano Mazzocchi
>>> <> wrote:
>>>> See? the problem is that you are partitioning the matching space 
>>>> with
>>>> URL matchers... I strongly feel that most of the problems that 
>>>> Daniel
>>>> (and you) are outlining will just go away if you used non-URL
>>>> matchers.
>>> Although I agree that 90% of the problem seems to be a matcher issue
>>> I've got to ask; what would the matchers be matching on if it's not a
>>> URL?  I have a couple answers, but I'd like other opinions...
>>> It seems to me that Daniel might be coming at this from a mostly
>>> application POV.  If so, for such cases, I think you can't _always_ 
>>> be
>>> quite as dogmatic about how a URL is structured; for many apps 
>>> there's
>>> little to no exectation of long term URI persistance/repeatability.
>> I don't see this. The application is the resource and it is the
>> application that should have a unique identifier. If the application
>> allows a user to perform multiple tasks you may want to consider each
>> task a resource.
> An app may be 1000's of resources.  The issue is how to find a
> rational way of getting 1000's of unique identifiers.

Hmmm... This is a question of semantics. To me the app is the only 
resource. Because I use the http protocol I am constrained as to how I 
issue commands and pass arguments. As a result I use constructs that 
appear to be URIs but in reality are just an awkward translation to 
something that looks like a URI. This does not diminish the problem but 
explains why it exists.

>> The persistence of the URI in general is not that
>> important from a users perspective since the URI identifies a resource
>> that might be reachable from multiple URLs. What is important is that
>> the URL that a user uses to reach an application persist and not 
>> change
>> as long as users may use the application.
> Umm, wasn't that my point?

Sorry, I just missed it. I'm glad we agree.

>> We may not expect to see
>> identical results each time we access 
>> but
>> we do expect to get the current weather forecast for New Orleans. If
>> switched the URI/L to,
>> as a user I would be perturbed to say the least.
> You're missing the point:


> weather is a published resource, it's not an
> application.

This was too simplistic an example with out the details. I should also 
not have used an existing site.  The point was a single 
application/resource can be accessed by two distinct  URLs and changing 
URLs is unsettling to a user.

> Consider something like a Web hosted SFA app, something
> where you need work flow. The hard point isn't getting to the app, the
> hard part is partitioning the app.  You've got lots' of orthogonal
> concerns (and I mean lots). URI, scheme (protocol), and request
> parameters (among others) all give you ways of attacking various parts
> of the problem,

Of course. And this is where problems in structuring a sitemap arise.

> but when you start hosting 1000's of different app
> spaces on the same machine the issue isn't as trivial as
> scheme://host?couple-of-parms.

What else do you have? This is pretty much it X 1000s. An application 
consists of its commands and queries. Each may have parameters. The 
problem is mapping the commands, queries and parameters to something 
that is a valid URI. Your sitemap can only do so much. With the advent 
of flow there is a very direct way to map public URLs to commands and 
queries. If you want to simplify (though not shorten) your sitemap use 
flow and match using a hierarchical menu like pattern (
	<map:match pattern="patients/edit">
		<map:call function="editPatient"/>

I realize that everything is not this simple. Many problems arise from 
technologies that have been supplanted by flow. Prior to flow there was 
a tendency to use the sitemap as the application controller. Using it 
as such probably leads one to much more inventive URI designs.

> You've got to allow for variations on
> authorizations, error handling, timeouts, resumed sessions, etc.

These do not have to be public URLs. All of these things are internal 
to the application. If you are providing your users with URLs for these 
things you should ask yourself if there is a better way to handle this.

>> As far as dogmatism and URL structure goes, you can always be dogmatic
>> in the way you structure them. ;-)  The problem with dogmatism is that
>> it does not always lead to the best solution for a given case. Then
>> again sometimes it does.
> And that's this issue Daniel's worried about: what's the best
> solution.  (However, I'm not completely sure for what problem space.)

As always, it depends on the problem space. ;-) There is not one best 
way and thats why implementing the sitemap according to the "best way" 
to design your URL space is probably a bad idea. I do find the idea of 
a tree structured sitemap appealing (even though it works nicely with 
my "best way" :-O).

Glen Ezkovich
HardBop Consulting
glen at

A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to 
worry about answers."
- Thomas Pynchon Gravity's Rainbow

View raw message