cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <>
Subject RE: defaulting to a matcher when another one is not present
Date Tue, 15 Oct 2002 16:12:21 GMT
>>>>How would you suggest handling it with Cocoon today?  
>>>Since you *have* to define up front between groups which URLS to use, 
>>>and define them with no general rule, simply make a FixedListMatcher 
>>>that matches based on fixed names in a list, so that you don't need an 
>>>expert system and just need to update a list.
>> No you don't have to define up front what groups use what URIs.  That's
>> whole point of using sub-sitemaps.  All I have to define is what part of
>> pattern each group uses.  
> Exactly. By making sitemaps return, you are *not* defining the pattern 
> each group uses. You are leaving it all to them.

Sigh, I am defining a pattern each group uses.  They may not fully use all
of each possible name space, that is true with Cocoon today.  More-over, I
am also defining a back up use of the name space if and when the two groups
agree that they are going to have an overlap.  The point is, it's not the
maintainer of the master sitemap that is writing the "contract" on how the
name spaces are being used.  It's two other groups (well actually half a
dozen, but that's another problem).

>> It's up to the groups to define what URIs to use,
>> not me.  
> Ok, then what's the problem?
> Can't they change the sitemap?

1) they can't change the master sitemap.  They can only change things in
their own directories.  

2) Currently they can make all the changes they want to a sub sitemap.
However, if someone else's sub sitemap gets control first their sub-sitemap
will never even have a shot at having the URI handled.  

>> I don't want to be in charge of this; I don't want anyone in our
>> group to be in charge of this.  I want the end users to work the URI
>> mappings out between them and I want the sitemap to still work when they
>> decide that one groups URIs overlaps the root of another groups URI. 
> Ok, then give them a subsitemap they use together.
> If they decide URIs together, they can surely work on the same shared 
> sitemap together.
> And have other subsitemaps there.

If it was just two groups that might be a reasonable solution.  What happens
when it's 6 and they don't trust each other (they have a long term political
history of not cooperating, thus the tortuous every 2nd Tuesday meetings
where they negotiate the web site lay out).  You end up with N combinatorial
combinations of directories and sub sitemaps if you have to allow for secure
and deterministic handling of each possible source of information.

I should point out, once more, that our real life situation has nothing to
do with the examples given here, though they are in many ways similar.  The
real version of the problem requires serving up research results from, at
present, over 600 different research protocols (we've got about 20
implemented), each of which is essentially administered as though it was an
independent kingdom, but with requirements to share information on a very
restricted basis.

>> The
>> fact that I give them default sub-sitemap matchers of "IT*" and "Stats*"
>> shouldn't be their problem if they decide that IT has a good reason to
>> "StatsSomethingStrange" for some specific URI. 
> Sure, then mount a sitemap and give it to them... both of them.

Can't be done, they would not ever agree to share a common directory for all
their information which is what this would require.  Now I could give them
the capability to define a sub sitemap that then delegated to two other sub
sitemaps.  However, now all I've done is shove the problem down a level and
the two groups will have the same requirement that I do.  More-over, for the
case when the problem has to be scaled to work with N groups you once more
have possibly N combinatorial sub-sitemaps deciding which sub-sub sitemap to
parcel the information out to. 

>> Once again, I ask you to tell me how to handle this situation with Cocoon
>> it currently sits?
> I have already said it. More than once.

No, you've come up with a solution that shares data instead of sharing
metadata and thus doesn't solve the problem.  The requirement is to allow
each group to securely maintain their own information while sharing some of
the same URI name space (not some of the same information). 

[snip of redundant discussion]

>> Throwing an error is not graceful behavior as far as an end user is
>> concerned when they have every reason to expect their URI mapping to
> You don't listen.
> If there is URL overlapping there is no way you can handle the situation 
> gracefully if the groups don't work together.

As I've repeatedly pointed out, the two groups do work together.  That's not
the problem.  The problem is how to allow them to share some common URIs (or
better Cocoon matching patterns) in a graceful manner without requiring the
maintainer of the master sitemap to be involved in coding up their
resolution to their problems.

>> You handle the mapping, you are in charge.
>They handle it, they are in charge.
> Read the SoC part of

Now that's ironic.  Here's the separation of concerns I need:

1) Master Web site maintainer, in charge of maintaining the application

2) Many independent groups, each with their own, securely served and
maintained data.

3) Ability for each combination of independent groups to come to agreements
between them on how to share URIs (really Cocoon matching patterns since you
can match on more than URIs) without involving the master web site

>> If you stop to think about it you'll realize this is true for almost any
>> system other than simple static screen displays:  what data is presented
>> based on session values, or request values, or cookie values, or
>> As such, saying that a URI map should _always_ be required to be
>> deterministic is nonsense.  
> Is it magic?

Sorry, I should have stated that as; "saying that the top level of a
hierarchy of URI maps should always be required to be fully deterministic,
in-and-of-itself, is nonsense".

I think you're missing a big chunk of the problem: it's not just URI
matching that's the problem here.  Cocoon sitemaps can match based on
(literally) 1000's of different pieces of information. You can considerably
simplify the coding of Cocoon sitemaps if you can move some of the
responsibility for handling the matching down to sub sitemaps without having
such a decision being isolated to a single sub sitemap.

>> There may be very good reasons for a sub-sitemap
>> to look at other values associated with a URI and reject the handling of
>> that particular URI.  There may be very good reasons why some other
>> sub-sitemap could then subsequently handle that particular case. If I
>> to code all the matching rules in the parent sitemap I've defeated the
>> purpose of the sub-sitemaps.
> Hmmm... manybe you've defeated *your* idea of subsitemaps.
> Linux can mount. Cocoon can. Same concept.

No, it's not the same concept (see the following)...

> Would you like the mount point to have a multiplicity?
> What file does the user get?

First off, we're not serving files, the analogy is flawed in it's conception
since if all you needed was file serving you wouldn't need Cocoon (Apache
would suffice). However, the decision on what information to be displayed
would still be based on whatever match is made first, the same as today.
I've just separated maintenance of the rules among multiple groups instead
of requiring them to all be maintained in one spot.  

Instead of thinking in terms of file matching think in terms of XSLT
template pattern matching; it's not restricted to just a single dimension of
matching (unlike file systems). Think of how restrictive XSLT would be if
call-template was not allowed to return to the calling template!  

> Read the *original* proposal of the sitemap in the archives, and you'll 
> understand why a sitemap is not reactive:

That doesn't change my argument, if anything, it enforces it: allowing a
sitemap to return allows me to build overlapping hierarchies of patterns
without having to code for all such possibilities in one spot.  As such, it
allows for better SOC, not worse.

>>  I've
>> given you many reasons why it could help people.
> It helps people do what I think is bad practice.
> A citation form Mazzocchi, which I think still stands:

Again, if anything this reinforces my argument. I'll try to show how by
interjecting my comments into the quote (though it seems sort of messy to do

> "
> 1) badly designed web sites will lead to verbose sitemaps, on the
> contrary, well designed web sites will need less verbose sitemaps.

Allowing returns from sub-sitemaps would allow one to code less verbose
sitemaps since you would no longer require that all possible URI patterns
are explicitly named in the top level sitemap.

[point 2 about being nice snipped]

> 3) a good sitemap grows step-wise logarithmically with the web site
> size. This means that once you've reached the needed web-site
> complexity, every addiction in the same patterns will not need to modify
> the sitemap, or, if it does, produces redesign rather than simple
> verbosity increasing.

Allowing sub-sitemaps would, in some cases, allow top level patterns to be
coded once and forever, without a need to ever redesign the top level
sitemap.  Changes would be isolated to incremental changes in sub-sitemaps.
It could considerably reduce the size of a sitemap since generic matching
rules can now be used in catch all sub-sitemaps when specific rules in prior
called sub sitemaps do not match.

> 4) Cocoon is _not_ designed for small sites. Small sites will have
> complex sitemaps compared to other solutions. This is why I do not
> recommend Cocoon for pure HTML replacement.

Allowing sub-sitemaps to return helps in the management of large web sites
by allowing negotiations on sitemap matching to occur on a one to one basis
instead of an N combinatorial basis. The maintenance of such sites can then
be parceled out to multiple groups knowing that they are free to manage the
site as they see fit without the involvement of some third party.

> 5) I assume sitemaps will be managed by learned people that keep control
> of the "contracts" between the working contexts. This is the
> "management" box in the "pyramid model of operation" (see Cocoon docs).

Allowing sub-sitemaps to return can allow the people who are negotiating the
pattern matching contracts to manage their contracts directly instead of
requiring that some master sitemap maintainer code the contract for them.

>> Even if you don't agree
>> with my reasons -- if you want people to respect your votes -- I believe
>> need to give us some real justification for not allowing this change
>> than the fact you think "it is not right".
> No listen to this! :-O
> I have not voted, 

Huh ?

shows you voting -1 on this issue ????  If that's not correct, or you'd like
to revoke your vote, then forget the whole issue...

> I have explained it as much as I can, I spent my time 
> explaining you how it can be done better, and this is the result?

Sorry, but you really haven't explained how to meet my concerns at all.
You've tried to map my problem to your way of using sitemaps, but that
doesn't address the real problem.

[snip on suggestion that research groups have copious spare time to maintain
independent branches of Cocoon source code]

>> However, I'd like you to once more go back
>> and look at this.  I for one strongly believe that the ability to
>> _optionally_ parcel out handling of a URI to multiple sub-sitemaps would
>> help for some organizations and that adding such capabilities to Cocoon
>> cannot hurt anyone.
> This "cannot hurt anyone" is the usual refrain. :-/

If you could really give me one real life example of how allowing this
change would hurt things I'd listen to it.  

[snip on introduction to following]

> Now, it seems to me that in your organization, you are the Cocoon admin, 
> and are in charge of the main Cocoon sitemap.
> There you can give groups subsitemaps that are mounted, thus 
> partitioning the space between them.
> Some groups work separately while still sharing the same URI space 
> somewhat, and try to work out the inconsistencies with weekly or 
> as-needed summits ;-)
> You want to be able to have them work *indipendently* on the *same* 
> mount point.

No, I want them to work independently on different mount points.  I want
them to share the responsibility for maintaining a URI name space (or more
correctly, maintaining Cocoon matching patterns). The problem is almost the
exact opposite of what you discuss. 

[rest of discussion snipped since it discusses how to share information and
not how to share matching capabilities]

To unsubscribe, e-mail:
For additional commands, email:

View raw message