Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <601F6322AD71D5118D6C0003472515290660D011@sjmemexc1.stjude.org>
From: "Hunsberger, Peter" <Peter.Hunsberger@stjude.org>
To: "'cocoon-dev@xml.apache.org'" <cocoon-dev@xml.apache.org>
Subject: RE: defaulting to a matcher when another one is not present
Date: Thu, 10 Oct 2002 09:41:55 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"

>> Is this necessary?  Probably not.  
>
> In fact, in the above scenario it isn't.

How would you suggest handling it with Cocoon today?  

>> Is there any reason not to allow it?
>> Probably not.
> 
> Let me disagree.
> 
> A sitemap is a *contract*.

Well that's the basis for the disagreement.  I don't believe a sitemap
should always be a strict contract, a sitemap should be a set of rules about
to handle URIs.  If these rules can be strictly encoded and enforced all for
the better, but if they can't I'd still like to be able to handle the
situation gracefully.

> It defines the URI space of your site, and URIs are hierarchical in
nature.

Even though the semantics of a URI are hierarchical, there's no need for the
mapping to business logic also be restricted to be hierarchical. 

> If you define the URI space *outside* of the sitemap ("but those can be 
> resolved through negotiation between the two sections") you are 
> effectively reducing the usefulness of the sitemap.
> 
> Since splitting URIs between groups is a rule, ie a *contract*, on the 
> URI space, it should be evident in the sitemap itself and defined 
> *before* the control is delegated to the subsitemaps, because it should 
> be negotiated between the parties *before* they start adding pages and 
> potentially stepping on their toes.

You are still encoding the external resolution of the discussion in the
sitemap.  The fact that the two groups agree to allow for name collision is
part of the "contract" so to speak...   Yes it's nice to be able to code
everything in nice provable procedural code.  Real life doesn't always work
that way. Our real life situation is much more messy, we'll eventually have
to code a bit of an expert system to resolve the business rules on what
information is presented for any given URI request.  The URI itself, in our
particular case is almost meaningless and at best only gives us hints on
what the user thins they want to see.

> Now, given that your groups don't want to tread on each other when 
> working, simply define the spaces they can manage in the main sitemap 
> and the problem is elegantly solved.
> 
> "we don't necessarily know how they will code their URL's and we
>   want each to have a shot at resolving any given URL."
> 
> Exactly what I want to avoid.
> URI spaces must be well crafted up front, and possibly self-describing 
> and easy to understand.

Well, that's all fine and good.   There's nothing in the proposal that would
stop you from creating such sitemaps.  Just don't use the optional
allow_return="true" (or whatever) attribute when you link your sub-sitemaps.


You still haven't given me any reason why the rest of us -- who don't
necessarily have such neatly compartmentalized worlds -- should have to
conform to that particular sitemap model?


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